セキュリティグループの作成単位、構成について
Gekitenius.Y既存のインフラを整理する流れで、セキュリティグループの作成単位や構成をどのようにすべきが迷った。
Gekitenius.Yとりあえず公式。
以下は公式からの留意しておきたい点などを抜粋
セキュリティグループごとに、プロトコルとポート番号に基づいてトラフィックを制御するルールを追加します。インバウンドトラフィックとアウトバウンドトラフィックには、個別のルールセットがあります。
作成単位や構成に関係するレベルではないけども基本的な仕様の確認
セキュリティグループはステートフルです。例えば、インスタンスからリクエストを送信した場合、そのリクエストのレスポンストラフィックは、インバウンドセキュリティグループのルールに関係なく、インスタンスに到達が許可されます。許可されたインバウンドトラフィックへのレスポンスは、アウトバウンドルールに関係なく、インスタンスを離れることができます。
戻りは考慮しなくてOK、こちらも作成単位や構成にはさほど影響し無さそう
VPC あたりの作成可能なセキュリティグループの数、各セキュリティグループに追加できるルールの数、ネットワークインターフェイスに関連付けることができるセキュリティグループの数にはクォータがあります。
これは考慮しないといけなさそうですね → 考慮事項１：クォータ
Gekitenius.Y今度は公式ドキュメントの中でもベストプラクティスを確認していく
特定の IAM プリンシパルのみにセキュリティグループの作成と変更を許可します。
セキュリティグループを誰が作成していいかという話なので趣旨違い。
エラーのリスクを減らすために、必要最小限の数のセキュリティグループを作成してください。各セキュリティグループを使用して、同様の機能とセキュリティ要件を持つリソースへのアクセスを管理します。
「せやな」案件、特に構成に影響し無さそう。
EC2 インスタンスにアクセスできるようにするために、ポート 22 (SSH) または 3389 (RDP) のインバウンドルールを追加する場合は、特定の IP アドレスの範囲のみを許可する必要があります。0.0.0.0/0 (IPv4) と ::/ (IPv6) を指定すると、指定したプロトコルを使用して、誰でも任意の IP アドレスからインスタンスにアクセスできるようになります。
これはルールの設定方法についての記述なので構成とは違うかな。
完全に影響しないわけではないけども。
広い範囲のポートを開かないでください。各ポートからのアクセスが、それを必要とする送信元または宛先に制限されていることを確認します。
「せやな」案件その２
セキュリティの追加レイヤーを VPC に追加するには、セキュリティグループと同様のルールを指定したネットワーク ACL を作成することを検討してください。セキュリティグループとネットワーク ACL の違いの詳細については、「セキュリティグループとネットワーク ACL を比較する」を参照してください。
ここは大事だろうな。
セキュリティグループとネットワークACLとで、どっちに何の役割を任せるべきかというのは知っておかないといけない。セキュリティグループの構成よりも大きい枠の話になるので、考慮事項として優先度高め。
→考慮事項２：ネットワークACLとの使い分け
Gekitenius.Y考慮事項２：ネットワークACLとの使い分け
重要性が大きそな考慮事項２から深堀り
とりあえずの公式。
大きく影響しそうなのはこの２点かな？
その他の項目も大事なんだろうけど、そこまでネットワークの経験が無さすぎて、その特徴がどういう重要性をもつのか判断できない。
なるほどね。だいぶ理解が進んできた。
正確な順序じゃないかもしれないけど、イメージとしてはこんな感じで通信が評価されていくと。
ルートテーブル（サブネット単位）
→ネットワークACL（サブネット単位）
→セキュリティグループ（インスタンス単位）
セキュリティグループのみを使用してインスタンスを保護できます。ただし、ネットワーク ACL は追加の防御レイヤーとして追加できます。
OK、理解は合っていたみたい。
考慮事項２の結論
同一サブネット内に属する、複数のインスタンス同士のアクセス制御についてはセキュリティグループを使用することになる。
サブネットの切り出し方と、サブネットにどのリソースを配置するかにもよってはネットワークACLでインスタンス同士のアクセス制御を実現できないこともなさそうだけど、そういう用途はセキュリティグループが担うものとして設計されていそう。
これらを踏まえると、セキュリティグループはインスタンスの役割単位や、それに準じた単位で作成・構築・運用していったほうが良さそう。
Gekitenius.Yセキュリティグループ、ネットワークACLと出てきたので少し寄り道してAWS WAFについても調べてみた。
AWS WAFについてはAWSアカウントのVPC外にあるみたい。
実際にコンソール画面から作成してみようとしたけど、リージョンの指定はあったもののVPCの指定はなかった（多分）。
後で自分が戻ってきた用に分かりやすかった記事を置いておきます。
昔々のAWSではEC2にWAFを載せてたみたいですね。
Gekitenius.Y考慮事項１：クォータ
次は考慮事項１の深堀り
上限については例のごとくクラスメソッドさんで良さげな記事が。
なるほど、１つのインスタンスにアタッチできるセキュリティグループは５つまでなのね。
ルールの方は１つのセキュリティグループあたり60までと（デフォルト）。
考慮事項１の結論
１リソースあたり５つまでのアタッチという関係上、細々と分けるものではない印象を受ける。
ケースバイケースとは言え、ある程度の大きさの粒度で切り出す必要がありそう。
Gekitenius.YここにきてQiitaで参考になりそうな情報が出てきて、ある程度方針が固まった。
ミドルウェア単位と役割単位の２つで意見が分かれたとのこと。
個人的には役割単位の方が良さそうな感じがした。
セキュリティグループの種類自体はいくつも作成できるので、初めのうちは役割単位で切り出してからの、そこから更に柔軟に細かくするニーズが出てきたときに、役割単位でのグループを細分化させる（役割A-1, A-2, A-3）という方針が良さそう。
とは言えミドルウェア単位で分けていたほうが直感的で管理もしやすい場合もありそうなので（SSH接続のためのものとか）、先の記事でも触れられていたように、ミドルウェア単位で管理するものと役割単位で管理するものを分けて運用していくのが現実的なのかなと思ったり。
そのバランスを考えるのがアーキテクトの仕事だから、方針はともかくバランスをとって設計していくためにはやっぱり、自分が携わっているドメインの理解を深めるしか無さそうだな。。
Gekitenius.Yぼやけてきたのでまとめ
とりあえず今回は将来のことを考えて、拡張性を持たせたいので、
- 基本は役割ごとにセキュリティグループを作成
- 明確に共通化して管理することが見えているものはミドルウェアごとにセキュリティグループを作成
という方針で行こうと思います。