![[レポート]AWSセキュリティリファレンスアーキテクチャ：セキュリティを視覚化する #reinvent #SEC203](https://devio2023-media.developers.io/wp-content/uploads/2021/11/eyecatch_reinvent2021_sessionreport.png)
[レポート]AWSセキュリティリファレンスアーキテクチャ：セキュリティを視覚化する #reinvent #SEC203
こんにちは、岩城です。
セッション概要
SPEAKERS
- Andy Wickersham
- Neal Rothleder
DESCRIPTION
AWSセキュリティサービスはどのように連携し、どのように展開するのか？新しいAWS Security Reference Architecture (AWS SRA)は、マルチアカウント環境でAWSセキュリティサービスを完全に展開するための規定のガイダンスを提供します。AWS SRAでは、セキュリティサービスをどのように導入・管理すべきか、セキュリティ上の目的をどのように果たすべきか、そしてそれらがどのように相互作用するのかを説明・実証しています。このセッションでは、これらの資産、AWS SRAチームの設計上の決定、およびセキュリティ設計にAWS SRAを使用する方法のガイドラインについて学びます。AWS上で独自のセキュリティ・アーキテクチャを設計・実装する際に役立つ、権威あるリファレンスをご覧ください。
SESSION LEVEL
- 200 - Intermediate
イントロダクション
- 私たちのモットーは、お客様が最も重要なワークロードをAWSに移行するための自身と技術力を持てるように支援すること
- これから紹介するガイダンスや事例は、すべて実際のユースケースに基づく
- 支援しているとお客様からの3つの要求があることが分かってきた
- セキュリティサービスの全体像をどのように考えれば良いのか
- セキュリティーサービスををどこに配置するのか
- 各セキュリティサービスをどのように連携させるか
レポート
AWS SRA
- お客様と繰り返し検討し、AWS Security Reference Architecture(SRA)を開発した
- マルチアカウント構造でAWSセキュリティサービスのフルセットをデプロイするためのガイダンス例と設計上の考慮事項のセット
- すべてのセキュリティサービスを含む1ページの図を作成したかった
- 公式ドキュメント
- 今のところすべてのサービスが含まれておらず、いくつか抜けている
- バージョン2がリリースされる予定、継続的にアップデートが行われる
- 私たちの目的は個々のサービスに深く入り込むことではなく、より広い範囲で全体を見渡せ、高品質なサービスを提供すること
- お客様が参考にできる信頼性と権威のある情報源にしたいと考えた
- お客様のワークロードが変化し、アプリケーションが変化し、新しいAWSサービスや新機能を導入することを理解している
- re:inventのようなイベントでは新サービスや新機能が発表されるが、SRAのドキュメントが古くなるのを避けるべく、常に最新の状態に保ちたいと考えている
AWS SRAがどのように役立つか
- SRAを使用して既に実装された設計や機能を見直し、自分が異なるやり方をしていることに気づく
- 違い自体は問題ではなく、なぜ自分が異なるやり方をしているかを考える
- 正当な理由であればドキュメントにする、もし、短期的なトレードオフで何かを実装して技術的な負債を抱えているのならば、優先度を上げて対応する良い機会となる
- 時々受ける質問に、SRAをとても気に入ったが、既に自分のアカウントではSRAとは違った方法で対応している、どちらかが間違っているのか、というのがある
- 大抵どちらも間違っていない
- SRAはあくまで参考資料であり、すべてのお客様やワークロードに対する答えではない
- SRAと違った実装でも問題ない
- SRAを基準として使用することを推奨する
Security foundations
- SRAは確立されたセキュリティの基礎の上に構築されている
- セキュリティ基盤や新しいセキュリティ原則を再発明しなくなかったので、既存のAWSセキュリティ推奨事項に沿っている
- AWS Cloud Adoption Framework(AWS CAF)
- クラウドの最適化など、組織がクラウドを利用する際に役立つ
- 6つの視点で構成されており、ビジネスに特化した3つの視点、技術的な3つの視点で構成されており、セキュリティの観点も含まれている
- AWS クラウド導入フレームワーク (AWS CAF)
- AWS Well-Architected
- ワークロードやアプリケーションを安全、確実に、効率的に、コスト効率よく構築するためのフレームワーク
- 5つの柱で構成されており、セキュリティの柱がある
- AWS Well-Architected
- 責任共有モデル
- SRAはお客様が責任共有モデルの一部を果たすために設計されている
AWS SRA: High-level account structure
- SRAで最初に気づくのは、AWS Organizationsによる大まかなアカウント構造であるということ
- Organizationには、いくつかのOrganization Unit(OU)があり、お客様やワークロードに対するインフラ使用のセキュリティがあり、それらOUの中に特定のAWSアカウントがある
- AWS Organizationsのガイダンス、ベストプラクティス、マルチアカウント戦略など、すでに存在するガイダンスにSRAは基づいている
AWS SRA: Security Tooling account
- セキュリティツールアカウントは、セキュリティサービスの運用、AWSアカウントの監視、セキュリティ、アラート、レスポンスの自動化に特化したアカウント
- 特に大企業では、複数のセキュリティツールアカウントを持つことが理にかなっている場合があり、それらに異なる名前をつけることがある
- 例）セキュリティ監査アカウント、読み取り専用アカウント、セキュリティオペレーションアカウント
- Security Hubを用いて、各サービスを統合する
- Security Hubは、2つの主要機能があり、調査結果の集約と収集と、セキュリティ基準に違反していればアラートを発するもの
- Security Hubは、APNのSaaS製品群からも調査結果を収集できるだけでなく、組織内のすべてのAWSアカウントから調査結果を集約することもできる
- 最近は複数リージョンの調査結果を集約する機能もリリースされた
- Security Hubを使用していなくても全く問題ない、SRAに照らし合わせて、SaaS製品で実現するのか、あるいは独自ツールで実現するのか判断すること
AWS SRA: Application account
- 多くのリファレンスアーキテクチャは、主要なワークロード、主要なビジネスアプリケーションに焦点を当てている
- そしてセキュリティは脇に追いやられるか、抽象化されているか、あるいは後続のドキュメントに記載されているかのいずれか
- SRAにより、セキュリティに焦点を当てたかった
- このケースはシンプルな3層構造のウェブアプリケーションであり、セキュリティは徹底的に拘った
- GuardDutyを始めとするセキュリティサービスをレイヤーごとに整理するというコンセプトが見えてきた
- 多層防御の考えで何層にもセキュリティ対策を施す必要がある
- 複数の防御層が重なり合うことで柔軟性が生まれ、より強化な保護が可能となる
Protecting the AWS organization and OUs
- トップレベルに組織があり、その中にOUが定義され、それぞれセキュリティOU、ワークロードOUという共通点、共通のガードレール、共通の許可モデルを持つ
- CloudTrailにより、組織内のすべてのAWSアカウントのAPIアクティビティをキャプチャし、証跡として1つの場所に集約することができる
- SCPにより、組織、OU単位でできることを制限することができる
- Resoruce Access Managerにより、組織内のアカウント感でリソースを簡単に共有できる
Protecting accounts
- 制御や監視の基本単位がアカウントにあるサービス
- アスタリスクがついているサービスは、アカウントレベルであり、組織レベルのサービスであることを示す
- Security HubやGuardDutyは基本的にアカウントレベルを監視するが、その情報を組織内で一元管理も可能
Protecting networks
Recurring guardrails and centralized management
- AWSの組織全体で一貫したガードレールと集中的な監視とガバナンスを実現する
- 緑の枠内にあるセキュリティサービスが一貫したガードレールのセット
- すべてのアカウントで同じサービスが提供され、各アカウントに一貫したガードレールを提供する
- Security HubやGuardDutyの調査結果は組織管理アカウントに集約できる
Protection with delegated administrator
- 組織管理アカウントはrootであるため、特殊なアカウント
- 組織管理アカウントにConfig、GuardDuty、Security Hubなどの情報を集約するのではなく、別のセキュリティアカウントなどに移すべき
- そこで「委任管理」という機能を使って、サービスの管理を任意のアカウントに移すことを検討する
AWS SRA code
- 紹介するコードはすべてGitHubに上がっている
- 環境全体でAWSセキュリティの設定を自動化したいお客様作業の経験から構築したソリューション
- お客様がソリューションに変更を加え、他の人がその恩恵を受けられると感じた場合はPRをしてほしい
- お客様がワークロード環境にデプロイする前に、PoCでテストしたいことを理解しているため、クリーンアップスクリプトを含めた
感想
私自身AWS Security Reference Architectureがあることを初めて知り勉強になりました。 CloudFormationテンプレートとクリーンアップスクリプトが用意されているので、自分でも試してみます。
特に以下の点を心に留めておきたいと思います。
- SRAはすでにあるガイダンスやベストプラクティスに基づいて設計されたアーキテクチャである
- SRAは判断基準であり、必ず守らなければだめなものではない、自分のアーキテクチャを見つめ直すきっかけにもなる
- セキュリティは脇に追いやられるか、抽象化されているか、あるいは後続のドキュメントに記載されているかのいずれかであり、SRAによってセキュリティに焦点を当てたかった
本エントリがどなたかのお役に立てれば幸いです。
