☰

プライベートサブネットへの SSH 用に AWS ネットワークアクセスコントロールリストを設定する方法

tag-icon • tag-icon ssh amazon-web-services access-control-list amazon-vpc
プライベートサブネットへの SSH 用に AWS ネットワークアクセスコントロールリストを設定する方法

私は AWS のコースを受講しています。2 台の Linux サーバーで VPC をセットアップしようとしています。2 つのサブネットで VPC をセットアップしました。各サブネットに 1 台のサーバーを配置しました。1 つのサブネットをパブリック、もう 1 つをプライベートにするというのがその考え方です。

2 つのネットワーク ACL を作成し、各サブネットに 1 つずつ関連付けました。

自分のマシンからパブリック サブネット内のサーバーに SSH 接続できます。そこからプライベート サブネット内のサーバーに SSH 接続しようとすると、接続タイムアウトが発生します。

SSH を機能させるために、2 つのネットワーク ACL にどのようなルールを設定する必要があるかわかりません。どなたか助けていただけませんか? 学習中なので、ルールの内容だけでなく、ルールの理由についても説明していただけるとありがたいです。

CIDR 10.0.0.0/16 の MyVPC という VPC があります。
最初のサブネットは MyVPCSub1 CIDR 10.0.1.0/24 です。2
番目のサブネットは MyVPCSub2 CIDR 10.0.2.0/24 です。MyVPCSub1
ルートに関連付けられた MyInternetRoute というルート テーブルがあります。ルートは次のとおりです。

|Dest        |Targ  |  
|10.0.0.0/16 |local |
|0.0.0.0/0   |igw   |

MyVPCSub2 に関連付けられた MyPrivate というルート テーブルがあります。ルートは次のとおりです。

|Dest        |Targ  |
|10.0.0.0/16 |local |

MyVPCSub1 に関連付けられた MyWeb というネットワーク ACL があり、次のルールが適用されます。

インバウンド:

| #   | Type | Protocol | Ports | Source     | A/D
| 99  | HTTP | TCP      | 80    | {My IP}/32 | D
| 100 | HTTP | TCP      | 80    | 0.0.0.0/0  | A
| 200 | HTTPS| TCP      | 443   | 0.0.0.0/0  | A
| 300 | SSH  | TCP      | 22    | {My IP}/32 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0  | D

アウトバウンド:

| #   | Type   | Protocol | Ports      | Source     | A/D
| 50  | ALL    | ALL      | ALL        | 0.0.0.0/0  | A
| 100 | HTTP   | TCP      | 80         | 0.0.0.0/0  | A
| 200 | HTTPS  | TCP      | 443        | 0.0.0.0/0  | A
| 300 | Custom | TCP      | 1024-65535 | 0.0.0.0/32 | A
| *   | ALL    | ALL      | ALL        | 0.0.0.0/0  | D

MyVPCSub2 に関連付けられた MyPrivate というネットワーク ACL があり、ルールは次のとおりです。

インバウンド:

| #   | Type | Protocol | Ports | Source    | A/D
| 100 | ALL  | ALL      | ALL   | 0.0.0.0/0 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0 | D

アウトバウンド:

| #   | Type | Protocol | Ports | Source    | A/D
| 100 | ALL  | ALL      | ALL   | 0.0.0.0/0 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0 | D

答え1

まず最初に、いくつかの用語の意味を定義します。

NACLS（ネットワークアクセス制御リスト）は、少ないサブネット レベルで適用されるパケット フィルター。「ステートレス」という側面は覚えておくことが重要です。つまり、サブネットに出入りするすべてのトラフィックを明示的に指定する必要があります。たとえば、「ステートフル」ルール アプローチ (AWS のセキュリティ グループが適用するもの) では、SSH の TCP/22 の受信トラフィックを指定するだけで、送信トラフィックが自動的に許可されます。NACLS ではそうではないため、トラフィックを通過させるには各方向にルールを指定する必要があります。

セキュリティグループ - これらは状態のグループです満杯VPC 内の 1 つ以上のインスタンスに適用できるルール。インスタンス レベルで適用されることに注意してください。セキュリティ グループは、従来のステートフル ファイアウォールに似ていますが、個々のインスタンス レベルで適用されるため、同じサブネット内でもインスタンスを互いに分離できます。また、ステートフルであるため、サーバーへのトラフィックを許可する場合 (SSH の場合は TCP/22 など)、対応するアウトバウンド ルールを作成する必要はありません。プラットフォームが自動的に処理するため、管理がはるかに簡単になります。つまり、エラーが発生する可能性も低くなります。

これら 2 つを比較したわかりやすい表があります。VPC セキュリティの比較

そのページには、フローの方向に応じてトラフィックに適用される順序を示すわかりやすい図もありますので、ぜひ確認してください。

サブネットに関しては次のようになります。

パブリックサブネット - AWSの用語では、これは単に、接続されたインターネットゲートウェイを介して0.0.0.0/0ルートを持つルートテーブルが接続されたサブネットです。

プライベートサブネット - これはその逆で、しない接続されたインターネット ゲートウェイ経由で 0.0.0.0/0 ルートを持ちます。環境内の NAT ゲートウェイまたは同様のプロキシ経由で 0.0.0.0/0 ルートを持つことはできますが、直接ではないことに注意してください。

問題は、NACLS とセキュリティ グループがある場合、どちらを使用するかということです。AWS は、NACL を「VPC のセキュリティのオプション レイヤー」と説明しています。一般的にはセキュリティ グループで十分であることは事実です。セキュリティ グループの方が柔軟性が高く、同じ保護を提供します。ただし、私の経験では、NACLS が使用される典型的なケースがいくつかあります。

  1. 既知の悪意のある行為者に対するブラックホール - 特定の IP 範囲から攻撃を受けた場合は、IP/サブネット ソースを完全にブロックする NACL を追加するだけで簡単に対処できます。
  2. チームに制御を委任する方法として、セキュリティ チームは大まかな NACL 構成 (たとえば、信頼できる企業ネットワークからのトラフィックのみを許可する) を適用し、その後、運用チームや開発チームが独自のセキュリティ グループ ルールを構成できるようにします。こうすることで、エンジニアがテストのためにインスタンスのセキュリティ グループをインターネットに公開しようとしても、NACL によってブロックされます。IAM を使用して NACL を変更できるユーザーを制限しながら、チームに他のすべてを制御するためのアクセス権を付与すると、大規模な環境での構成ミス エラーに対する優れたバックストップとして機能します。

AWS では、ここで利用可能ないくつかの構成シナリオに関するガイダンスも提供しています。VPC に推奨されるネットワーク ACL ルール

ただし、私のアドバイスとしては、通常、セキュリティ グループは適切な保護を提供し、理解と構成が容易で、適用がより柔軟できめ細かいということです。NACL は、人為的エラーやより高度な構成に対する追加のバックストップを提供しますが、基本的な用途では通常使用されません。そのため、AWS ではこれを「オプション」と呼んでいるのだと思います。

NACL をデフォルト構成のままにして (すべてのトラフィックの入出力を許可)、代わりに今のところはセキュリティ グループに焦点を当てます。NACL を 2 番目のレイヤーとして使用すると、シナリオで必要のない複雑さがさらに増すだけだからです。学習の観点からは、NACL が存在し、ステートレスであり、サブネット レベルで適用され、ルーティング決定の後、サブネットに入るトラフィックのセキュリティ グループの前に適用されることを知っておくとよいでしょう。

あなたの特定の状況に関しては、NACLを使用しているので、それが州法であることを覚えておく必要があります。少ないしたがって、サブネットに出入りするすべてのトラフィック フローを考慮する必要があります。これが、セキュリティ グループが非常に簡単になる主な理由です。したがって、あなたの場合は次のようになります。

  • あなたの IP から TCP/22 でパブリック サーバーにトラフィック - はい - ルール #300 受信
  • パブリック サーバーからの戻りトラフィックを、戻り SSH トラフィック用の高ポートで送信します - はい - ルール #50 アウトバウンド (ただし、ルール #300 ではありません - 以下を参照)
  • パブリックサブネットからプライベートサブネットへのアウトバウンドトラフィックは TCP/22 で送信されます - はい - ルール #50 アウトバウンド
  • パブリックサブネットからプライベートサブネットへの受信トラフィック - はい - ルール #100 受信
  • プライベートサーバーからプライベートサブネット上のパブリックサーバーへのトラフィックを返します - はい - ルール #100 アウトバウンド
  • プライベートサーバーからパブリックサーバーへのトラフィックを返す公共サブネット - ああ、いいえ、ハイポート (SSH クライアントがパブリック サーバーでプライベート サーバーへの接続を開始するために使用している一時ポート) をプライベート サーバーから戻すことを許可するルールはありません。

ルール #300 のようなルール (ただし、ソース IP のフォーマットが少し間違っていることに注意してください - 以下を参照) を、アウトバウンドのパブリック サブネット ACL に追加する必要がありますが、インバウンドではソースはプライベート サブネットです。セキュリティ グループが適切に構成されていると仮定すると、準備は完了です。

お役に立てれば幸いです。

追加すると、他の回答のとおり、パブリック サブネットの送信ルール セットのルール #300 の形式が間違っています。0.0.0.0/0 であるべきであり、0.0.0.0/32 ではありません。ただし、このケースでは、ルール #50 が最初にヒットし、とにかくすべてのトラフィックが許可されているため、これにヒットしていませんでした。したがって、機能しないとしても、実際に問題を引き起こしていませんでした。

答え2

ACL はステートレスです。

「パブリック」サブネットが、プライベートサブネットからの SSH 接続の戻りパスをブロックしている可能性があります。受信側のすべてのポートに対しても送信と同等のルールが必要ですが、サブネット範囲 10.0.2.0/24 に制限することもできます。

追加編集: また、0.0.0.0/32 の送信ルールは間違っています。IP が正確に 0.0.0.0 でない限り、機能しません。

関連情報