AWSのIAMセキュリティ運用設計の実践的な基本ルール
エンタープライズ案件におけるAWSのIAMセキュリティ運用設計のざっくり基本ルールです。ご参考ください。主にCIS AWS Foundations Benchmark コントロールの延長線上でAWSをセキュアにより便利に使うためにIAMの設計で考えるべき点をまとめました。
- 最初のAWSアカウント開設時に作られるAWSのルートユーザーは使わないようにする。すべてIAMユーザーを発行して使う。
ルートユーザーじゃないと出来ない事（ルートユーザー 認証情報が必要なタスク）のときだけ、ルートユーザーを使う。 - ルートユーザーの秘密の質問が設定されていること（ルートユーザーのパスワード紛失時に必要）
- IAMユーザーに直接IAMポリシーをアタッチしない。
- IAMグループにIAMポリシーをアタッチして、本番環境アプリ開発者グループ、本番環境アプリ運用担当者グループ、本番環境インフラ担当者グループ、本番環境緊急メンテナンス対応グループ、本番環境顧客個人情報アクセスグループ、本番環境IAM管理者グループ、本番環境KMS管理者グループ、本番環境administratorsグループ、本番環境監査専用ReadOnlyグループ、開発環境アプリ開発者グループ、開発環境インフラ担当者グループ、MFA強制とパスワード変更権限付与グループ、の様に役割や権限別のIAMグループを作り、各種IAMグループにIAMユーザーを所属させる
- ルートユーザーを含めて全てのAWSユーザーで多要素認証（MFA）を必須にする。AWS:MFA で認証された IAM ユーザーがセキュリティ認証情報ページで自分の認証情報を管理できるようにするのJSONを参考にForceMFA and ChangePassword のIAMグループを作成し、すべてのIAMユーザーをForceMFA and ChangePassword のIAMグループに所属させます。
- IAMグループへアタッチできるIAMポリシーは10個までとなっています。したがって、「AWS管理ポリシー」をIAMグループにそのままアタッチしているとIAMグループにIAMポリシーを追加できなくなります（「AWS管理ポリシー」を使うと、1つのIAMグループにアタッチするIAMポリシーが10個を超えることは結構多いです）。IAMグループのIAMポリシーは、「カスタマー管理ポリシー」を利用し、IAMポリシーのStatementのSidについても内容を理解しやすいように命名ルールを決めて守ること。
- AWS構築の前に最初にCDPを書き、予め利用するAWSリソースを把握しておき、タグ名「Name」やタグ名「env」などのAWSリソースネーミングルールをこの時点から作る。AWSリソースネーミングルールは、ハーバード大学のCloud Resource Naming Conventionsや弊社で使っているAWSリソースの命名規則を紹介しますなどが参考になります。リソースネーミングをおろそかにすると、AWSリソース管理のミス誘発要因や担当者変更引継ぎの精度低下に繋がるため非常に重要です。ACMなどリージョンもリソースネームに考慮したほうがいいものもあります。
（CDPは、AWS構築が始まった後に最適化や機能追加などで変化していくことも想定しておく必要があります） - 各種AWSリソースのタグ値のリソースネーミングルール（タグ名「Name」）は、各種AWSリソースの利用開始の最初の１個目から確実に適用すること。※AWSアカウント1つで全環境を運用する場合は、タグ名「env」もこの段階で必ず設定していくこと。
- IAMポリシーの「カスタマー管理ポリシー」のStatementのSidのネーミングルール、KMSのネーミングルール、ELBのターゲットグループのネーミングルール、ネットワークインターフェイスのネーミングルール、プレイスメントグループのネーミングルールなど、細かいところまでネーミングルールを浸透させ、わかりにくいネーミングルールは修正してリソース認識のわかりやすさに対して改善更新を永続すること。
- EC2インスタンスは、IAMロール経由でIAMポリシーをアタッチすること。そのため、IAMロール名に個別の役割を記載するのは非推奨。
- S3バケット、S3エンドポイント、EC2インスタンス（IAMロール）、VPCエンドポイント、Route53リゾルバエンドポイント、などにおける通信経路のポリシー管理をしっかり行うこと。※フルアクセスのアスタリスクによるポリシーをそのまま適用しない様に必要最低限の個々の経路を指定してください。後から必ず後悔しますので、対応している時、その脳みその状態でその時にやりましょう。後から思い出したり再学習するのも時間の無駄。
IAMユーザーの顧客個人情報アクセス権管理を徹底する
「RDS」、「RDSスナップショットのバックアップ」、「RDSスナップショットのS3バックアップ」、「RDSのCloudWatchLogsグループのストリームのgeneralとslowquery」など、アプリケーションを利用する顧客情報データベースや顧客情報データベースバックアップ、顧客情報データベースのログを閲覧できるIAMユーザー（IAMグループ）を固定IPやリソースタグ（やCloudWatchLogsならストリーム）などで制限する。
環境別にAWSアカウント複数持ちを強く推奨
本番環境、ステージング環境、検証環境、開発環境など、環境別に利用可能なIAMユーザを変える。1つのAWSアカウントで全環境の管理を行うと『「タグ名」：「env」』と『「タグ値」：「production/staging/test/developmentなど」』をAWSインフラ構築初期からAWS全リソースに絶対に設定する必要が出て来ます（おそらく120％の確率で抜け漏れが発生する・・・）。さらに、ELBのネットワークインターフェイスなどは自動で作り直しされ、リソースネームが安定しません。ELBのターゲットグループやEC2のEIPやACMのバージニア北部のSSL証明書、KMSのカスタマー管理型のキー、など細かいところまでenvタグをつける必要が出てくるのでプロジェクトチーム全体でリソースタグのネーミングルールを守るコストがそれなりに高いです。
そのため、管理的にも非常に手間がかかるので「本番環境」のAWSアカウントを1つ、そして「それ以外（ステージング環境、検証環境、開発環境など）」でAWSアカウントを1つ、の様に最初からAWSアカウントを2つ以上準備しておくことが強く推奨されます。別々のAWSアカウント間でassumeロールを使ったクロスアカウントアクセスを設定することで複数のIAMユーザーを使い分けるログイン認証まわりの負荷を減らすこともできます。
AWSアカウント2つ以上で暗号化状態で環境をまたいでEBS共有やS3共有などのストレージデータ共有を行う場合、KMSの暗号化キーも共有するなど、手順がややこしくなります。AWSアカウントを2つ以上で運用することについて、プロジェクト開始前に一番最初に検討すべき重要なポイントです。
プロジェクトチーム全体でIAMの設定情報を共有し協力して改善する
プロジェクトチーム全体でIAMの設定情報を共有し、各自が理解できるところまでIAM設計設定者にてプロジェクトチームを導く必要があります。「どこの誰のどのAWSリソースによるどのアクションが出来る/出来ない」というカオス状態を意図的につくるのがIAMです。IAM設計設定者にいちいち対応手間の負荷がかかり、開発が遅れる場合も出てきます。
IAMやKMSのReadOnlyグループを作り、必要なIAMユーザーを所属させて、プロジェクトメンバー各自がアクセス制限の妥当性をIAMポリシーなどのjson視認で確認出来る様にします。逆に、IAM設定が間違っている部分の指摘をIAM設計設定者がチームメンバー全員から受けられる状況にすることも大事です。IAM設計設定は複雑な上に、複数のIAMユーザーを巻き込むため検証コストが非常に高いです。IAMの設定を行う前にテストを行っても、IAM設定後に権限設定をうまくできていない部分が出てくることもありえます。プロジェクトチーム全体で一丸となって、協力して前向きに改善に取り組む姿勢がセキュリティ性確保のためにも重要です。
