前提条件レポートまとめこんにちは。クラウドリードチームのフクナガです。徹底解説」というセッションを視聴しました。このセッションを視聴して得られた知見などをレポートします。上に多様なシステムを構築するにあたって、全社共通のセキュリティ設定を行いたい場合があります。このセッションではテンプレートを使ってAWS環境のガバナンスを実現する考え方をご紹介します。(CDK)コードを使うことのメリットについて、開発者が解説します。中央集権型(ゲートキーパー)ツールの利用を管理者が承認することが必要な方式になります。変更作業の手順の事前作成/承認や作業再鑑など、この方式を利用するケースが多いと思います。管理者の業務が発生する限り、管理者がボトルネックになりアカウント数の増大が難しくなってくるためAWSでは推奨されないという説明がありました。権限のコントロールが完璧にできている(できていると証明できる)場合でない限り承認を挟まざるを得ないかなと感じてしまいました。分散管理型(ガードレール)利用者が自由に利用可能な代わりに、利用可能な範囲を事前に設定する方式になります。以下の2つの統制方式を組み合わせながら、セキュリティを高めていきます。利用できない操作をあらかじめ設定で禁止する方式です。SCPなどを利用して実施することを想定していて、ガードレールを敷く作業にあたります。CloudTrailなどを利用して実施することを想定しています。実際に、道を走っていく中で「ここ危ないよね。」っていう場所を見つける作業にあたります。発見的統制にあたる設定を実施し、運用しながら予防的統制をすべき項目を洗い出していくのが推奨です。分散管理型の考え方はしっかりと覚えておくべきでしょう。テンプレートによるガバナンス実現方法ガバナンス観点で利用するAWSマネージドサービスをテンプレートで構築する場合に推奨される手順が以下のように説明されていました。StackSetsを利用したり、CloudTrailで組織の証跡を有効にするなど共通運用チームが一括で管理することも可能ですし、各アカウントの管理責任を各チームが負うモデルだと、セキュリティへの知識レベルによって差が生まれてしまいそうです。知識レベルが生まれても問題ないように、必要最低限のセキュリティレベルをテンプレートで担保することが大事ということでしょうかね。利用者の知識レベルによりますが、責任範囲や運用手順(管理方法)については共通運用チームから連携/教育していく必要があります。テンプレートによるガバナンスの考え方テンプレートを用いる場合のガバナンスの考え方について、以下のように説明されていました。自社に最適化した仕組みを作るより、AWSサービス拡充の柔軟な取り込みを上記は、あくまで「推奨」で各利用者の状況に合わせて仕組みづくりをしていきましょうという内容だそうです。Configの非準拠AWSリソースを修復アクションで修復するのが知られています。https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/remediation.html逸脱した場合の修復方法を用意するのはなかなか難易度が高いため、まずは逸脱を検知する仕組みを構築することを目指すとよいと思います。CDKを利用して開発されていて、下記Githubで公開されています。https://github.com/aws-samples/baseline-environment-on-awsファイルやドキュメントがかなりあり、利用方法についても説明が記載あります。Githubにて公開されているテンプレートを各要件に合わせてカスタマイズを実施し、独自のテンプレートとして利用することを想定されているそうなので、利用するまではかなり勉強が必要です。CDK以外のコード化ツールを利用する想定の案件では管理が煩雑になるため利用を検討することが必要と考えています。CDK、その他はTerraformという煩雑な構成になってしまいます。CDKで実装されたBLEAを勉強してリソースの設定を把握し、利用するコード化ツールで実装しなおすことが必要です。まとめAWSにおいてインフラ構築テンプレートを用いたAWS環境のガバナンスについて実現方法や考え方についてご解説いただきました。セキュリティ関連設定については、アカウント間での差異も少ないのでテンプレートをうまく活用し、社内でのレベルを合わせていくことが重要だなと感じました。BLEAについては、内部の実装についても勉強し社内でのAWS利用に生かせればと思います。Summitフクナガインフラエンジニア歴5年のフクナガです。多めで発信していますが、CI/CDやIaCへの関心も高いです。休日はベースを弾いてます。