- とてもベーシックレイヤーなところの話しです
- 方々で語られている内容なので、目新しさはなーんにもありません
- AWS触り始めたのが最近なので、Classic環境ではなくVPC環境しか知りませんのであしからず
- IAMなにがし、とか、そういうのはまた別の機会にて
Security GroupとNetwork ACL
- ネットワークレベルでのアクセス制限を設定する道具として、AWSには以下の2種類のテクノロジがあります
- Security Group
- Network ACL
- Security GroupとNetwork ACLは同時利用可能
- 評価は両方の条件で判定を OR して、どちらかが拒否した場合、その通信は拒否されます（拒否が優先条件）
それぞれの特徴
Network ACL
- InboundとOutboundの通信についてプロトコル、アドレス、（TCP/UDPの場合）ポートを指定して許可・拒否を設定出来る
- Inboundを許可したトラフィックに対応するOutboundを自動的に許可すると言うようなステートフル動作はせず、ステートレス動作です
- ステートレスである為、任意の通信を許可しようとした場合、Outboundについてはかなり広いポート範囲を通信許可する必要があります
- 通信元や通信先はネットワークアドレスで指定します
- ルールセット内で評価順序を設定出来ます
- ルールセット内の評価順序が早い（強い）所に許可がある場合、後に拒否があっても、その通信は許可されます
- ルールセットはサブネットに割り付けます
Security Group
- InboundとOutboundの通信についてプロトコル、アドレス、（TCP/UDPの場合）ポートを指定して許可を設定出来る
- Secutiry Groupに書かれていない条件は拒否扱い（逆説的に、明示的拒否は設定出来ない）
- Inboundを許可したトラフィックに対応するOutboundを自動的に許可できる（逆も同様）ステートフル動作をします
- 通信元や通信先はネットワークアドレスだけでなく、セキュリティグループのIDを指定する事も可能
- ルールセットはインスタンスに割り付けます（実際にはユーザーが作ったEC2インスタンスだけでなく、色々なAWSリソースに割り付けるシーンがあります）
Network ACLの扱いにくい点
Network ACLを使うと、一般的な構成の利用をした場合、Outboundについて広く許可しないと通信不能になります（送信元ポートを限定する設定が可能であれば別の話ですが…そういう物はあまり見たことがない）。
例えば、Webサーバーの場合、以下のようにInboundに対してOutboundを非常に大きく開く必要があります（参考例です。Outbound側はOSやプログラムによって利用されるポート範囲が異なりますので、利用するOS・プログラムのドキュメント参照のこと）。
| 方向 | ポート/プロトコル | アドレス | 可否 |
| :-----: | :----- | :-----: | :-----: | :-----: |
| Inbound | 80/tcp | 0.0.0.0/0 | Allow |
| Outbound | 1024-65535/tcp | 0.0.0.0/0 | Allow |
また、Inboundに対応したOutboundが動的に許可されているわけではなく、静的に開いた状態にする必要がある為、対応するInboundトラフィックが存在しないOutboundトラフィックを発生することが可能となってしまうという問題もありますので、ネットワークレベルでのアクセス制限を実現する為には、Security Groupとの併用が望ましいと考えられます。
Route Table
- ルーティングの設定をサブネットごとに割り付けするテーブルです
- 複数作成出来ますが、サブネットにアサイン出来るのは1つのテーブルのみです
- ルーティングする対象ネットワークのネットワークアドレスと、送信先のゲートウェイを記述します
- ゲートウェイはIPアドレスまたは、インスタンスID（ENIのID）を書く事が出来ます
- VPCのネットワークアドレスはデフォルトで記述されて、かつ、ローカルに存在すると定義されています（かつ、削除出来ません）
- ↑の仕様があるので、ルーティングベースでサブネット間の通信を遮断するのは困難であり、Network ACLやSecurity Groupを利用して遮断を試みる必要があります（裏技的に、ブラックホールルーターを作り出して、そこにルーティングさせてしまうという手もありますが…）
S3エンドポイント
- つい最近追加された機能で、VPCの内側にS3へのアクセスエンドポイントを生成できる機能です
- IGWを設置せずともS3へアクセス出来る様になる為、S3へのアクセス目的でIGWの設置やNATの設置をしていた場合、これらを外す事が可能になります
- VPC内からインターネットに接続させる必要はないが、S3は使いたい為、やむを得ずIGWやNATを設置していたというパターンにおいて、これらを外せる大きなメリットがあります
- S3自体はパブリック空間に存在する為、アクセス制限の設定を誤ると、外部にデータ公開してしまうリスクはそのままです
- エンドポイントを作っただけでは利用出来ず、ルーティングテーブルへの追加（S3エンドポイントへのルーティングが自動で追加されます）と、エンドポイントへのアクセス許可（エンドポイントのIDに向けたOutboundトラフィック）を設定する必要があります
- Network ACLでアクセス先（Outboundトラフィック）を絞った設定をしている場合、相性が悪い可能性があります（エンドポイントのアドレスがはっきり為ず、IDでの表現になる為）
- Security GroupのOutboundに制限設定をしている場合（0.0.0.0/0に対する許可をしていないなど）、エンドポイントIDを対象としたOutbund HTTP/HTTPSのトラフィックを許可する必要があります（HTTPSのみでアクセスする場合は、HTTPは不要）