はじめに
AWSによって 「AWS Security Reference Architecture (AWS SRA)」 と呼ばれるセキュリティリファレンスアーキテクチャが公開されています。
SRAは、AWSのセキュリティ対策をどう実装すべきかを指し示すガイドとしての位置付けであり、SRAを参考にすることで、AWSの数多くのセキュリティサービスをマルチアカウントの環境に最適化する形でデプロイする方法が分かります。
本記事では、このSRAの中身を紐解き、SRAを活用してAWSアカウントのセキュリティ対策がどう実装できるのかを記します。
企業の課題
オンプレミスからAWSにサーバ環境を移行し始めたばかりか、既にAWSを利用して様々なアプリケーションを使いこなしているかどうかに関係なく、AWSアカウントにおけるセキュリティアーキテクチャの構築方法、構築後のアップデート方法は、全ての企業が共通して抱えている課題と言えます。
最近では、企業がAWSアカウントをワークロードごとに作成して、複数のアカウントを管理することが当たり前となりつつあり、何を共通化して何を個別化すべきなのかを考えることも必要です。
セキュリティアーキテクチャは、企業によって異なっており、中には複雑かつ煩雑となっているケースもあります。
また、AWSのセキュリティサービスは数多くあり、これらは日々アップデートしていくため、キャッチアップして設定をアップデートしていくことにも体力がかかります。
SRAの目的
AWSによれば、この「AWS SRA」は、AWSアカウントを利用する各企業が、セキュリティ対策を継続的に改善できるようにすることを目的としてリリースされているものです。
SRAをセキュリティ対策に役立てることで、前述の課題事項に関する検討作業の負荷を軽減することに役立つと考えられます。
SRAの構造
AWSアカウントのセキュリティを設定する箇所を層で考えると、以下の6種類があります。SRAは各層でどういったセキュリティ対策を行うべきかを定義するものとなっています。
(1) AWS Organizations (root)
(2) AWS Organizations (OU)
(3) メンバーアカウント
(4) ネットワークおよびコンテンツ配信
(5) AWSのプリンシパル
(6) AWSの各リソース
(1)(2) AWS Organizations
6つの層の最上位は「AWS Organizations」や、これと連携するサービスによって制御されます。
AWS Organizationsを中心に、所属するAWSアカウント全体の範囲でガバナンスと制御機能を適用するためのサービスと機能を利用していきます。
最も分かりやすいサービスを挙げると、AWS Configでは、様々なAWSリソースの構成を管理し、ルールから逸脱して変更された場合の自動修復を実装できます。
AWS Organizationsでは、サービスコントロールポリシー(SCP)を、IAMベースのポリシーで構築でき、予防的ガードレールに使用できます。
この層でSCPを適用すると、その効き目はメンバーアカウントにも継承されるため、1箇所で一元かつ統合的にアクセス(操作)権限を制御できます。
また、セキュリティ対策はAWSのマネージドサービスをただ使うというだけでなく、その使い方も継続的に評価される必要があり、例えばルートアカウント(最上位権限)をログインに使用していないなどの一般的なベストプラクティスを評価するために、AWS Seucrity Hubを使用できます。
(3) メンバーアカウント
AWS Organizationsの管理アカウントではなく、各メンバーアカウントで設定すべきものとして定義されているサービスです。
例えば、各メンバーアカウントで、各々のアプリケーションで使用する独自の認証情報(シークレット)の組み合わせを扱う場合に、AWS Secrets Managerを利用します。
IAMで開発者やアーキテクトにSecrets Managerへのアクセス許可を与えて、認証情報とパスワードを管理させ、ローテーションすることもできます。
本番環境ではアプリケーションがSecrets Managerから認証情報を取り出して使用することで、認証情報をアプリケーションにハードコードする必要がなくなります。
AWS IAM Access Analyzerは、各メンバーアカウントから発生するパブリックアクセスに関する調査結果を生成できるため、各サービスの設定がどのようであろうとも、各メンバーアカウントで現在発生しているアウトバウンドアクセスを俯瞰でき、各アクセスを許容するのか否かを評価できます。
許容できない場合に、どの層で設定すべきアクセス制限なのかを判定し、設定することができます。
また、各メンバーアカウントのAWS KMSをデータの暗号化に使用します。
S3アクセスログなどから、何らかの手段で不正と思わしきアクセスを検知した場合、CMKを無効化することでアクセスを封鎖できます。
CMKは複数のアカウントを跨いで使用できますが、あまり影響範囲が広がりすぎると、全封鎖か否かという極端な選択を迫られることになるため、メンバーアカウント単位での管理とするのが望ましいでしょう。
(4) ネットワークおよびコンテンツ配信
各メンバーアカウントで構築されているネットワーク、コンピューティングリソース、コンテンツ配信機能を保護するためのセキュリティです。
AWS Inspectorによって、各コンピューティングリソースの脆弱性管理を行い、保護します。
AWS Network Firewallをネットワーク全体のアクセス制限に使用し、アプリケーションをDDoS攻撃から保護するためにAWS Shieldを使用します。
(5)(6) AWSのプリンシパル、各リソース
AWSのサービスプリンシパルや、リソースのIDなど狭い範囲を指定して、個々のアクセス(操作)権限について、IAMロールやポリシーでアクセス許可を設定していくことが基本となります。
先に挙がったAWS ConfigとIAM Access Analyzerで得られる分析を参考に、上記のアクセス許可を個別に設定します。
SRAにおけるOUの分割と機能の配置
SRAでは、次の図の単位でOU(AWSアカウントをグルーピングして管理する単位)を分割して、機能を配置することを推奨しています。
SRAの解説を紐解き、rootも含めて掘り下げていきます。
(0) root OU (AWS Organizations 管理アカウント)
図中の左上の枠は、AWS Organizationsの管理アカウント自身で、全てのメンバーアカウントを作成して管理するための機能を持ちます。
また、AWS利用料を一括して支払うための機能を持ちます。
(1) Security OU
Security OUは「Security Toolingアカウント」と「Log Archiveアカウント」の2種類を管理するものとして定義されています。
Security Tooling アカウント
AWSのセキュリティ系サービスの運用とAWSアカウントの全体のセキュリティ状況の監視に専念し、アラートと応答を自動化します。
このアカウントで、セキュリティチームがあらゆる種類のセキュリティ検出結果を監視できるようにします。
「Log Archive アカウント」にあらゆるログを蓄積しておき、このログを参照して追跡するための機能も、このSecurity Toolingアカウントで実装して維持していきます。
例えば、AWS Security Hubのダッシュボードを確認すると、各業界や規制の枠組みに合わせて自動化されたセキュリティチェックの実行状況と、セキュリティ項目に対する達成状況が分かります。
Security Hubでは、機密データへのアクセスを検出するためにAmazon Macie、複数のログから潜在する脅威を検出するためにAmazon GuardDuty、ネットワークに潜在する脅威を検出するためAWS Firewall Managerと連携します。
Security Hubは、検出結果をAmazon Detectiveに送信し、データを視覚化するため、根本原因の調査に役立ちます。
また、Security Hubは、セキュリティに関連するルールではAWS Configと連携して機能するため、セキュリティに関する準拠状況も把握できます。
このAWS ConfigはAWS Audit Managerと連携し、Configルールへの準拠状況をAWS Audit Managerの出力に使用できるため、企業が監査評価レポートを作成するのにも役立ちます。
Log Archive アカウント
さまざまなログを集約して保管することに特化した専用アカウントです。
全てのアカウントのログを中央で保管し、Security Toolingアカウントの機能で一元的に分析できるようにします。
(2) Infrastructure OU
AWSアカウント全体の運用の基礎となる機能を持つAWSアカウントを管理します。
Shared Services アカウント
AWSアカウントに存在するリソース全体に対して提供したい機能を「共有サービス」として持ちます。
例えば、AWS Systems Managerでは、Amazon EC2インスタンスの構成を管理できます。
Systems Managerは、EC2インスタンスを保護するための機能を備えており、例えばOSのパッチ適用状況の管理を行えます。
AWSアカウント全体の認証を管理するために、AWS Directory ServiceまたはAWS Managed Microsoft ADが必要となる場合、これもShared Services アカウントに配置します。
(3) Workload OU
アプリケーションが実行されるAWSアカウントを管理します。
Application アカウント
Application Accountは、以下のようにアプリケーションを実装するためのインスタンスを起動するAWSアカウントです。
EC2インスタンスやAurora DBインスタンスはあくまでも例であり、ECSのコンテナインスタンス、Lambda関数、DynamoDBに置き換わることもあります。
Shared Service アカウントで、AWS Systems Managerを利用して管理を行うために、Application アカウントのEC2インスタンスにエージェントをインストールします。
EC2インスタンスにエージェントをインストールした後は、OSパッチを使用してEC2インスタンスの更新を管理したり、SSHで直接通信させないように管理したりします。
また、VPCにエンドポイントを作成すれば、インターネットに出ることなく他のAWSのサービスに接続できます。
この他、KMSで暗号化キー、Systems Managerで認証情報をそれぞれローテーションして管理します。
AWS SRA Code Repository
SRAは、AWSがGitHubにコードとして公開しており、誰でも入手して使うことができます。
https://github.com/aws-samples/aws-security-reference-architecture-examples
まとめ
AWSのセキュリティ関連サービスは幅広くリリースされており、シングルアカウントでも多数のサービスをどう有効化するのか迷うところですが、マルチアカウント管理と結びつけて考える場合には、どのサービスのどの機能をどこで実装すべきかという判断が加わり、その組み合わせが非常に多く、意思決定に時間がかかるのに加え、運用も管理も複雑かつ煩雑となりがちです。
また、認証や暗号化など、後からポリシーを変更することが難しい(面倒)な機能もあり、判断は慎重となりがちで、中々これだと決められないという課題もありました。
SRAによってベストプラクティスが明快に示されることにより、とりあえずこのアーキテクチャを採用して始めようという判断ができるようになります。
ただし、各人が仕様の理解を放棄できるわけではないので、このSRAによってどこに何がどういう意図で実装されているかを理解することは、引き続き必要です。
このSRAを実装する前に、まず中身を理解しようとトライしてみるだけでも、AWSのマルチアカウント前提のセキュリティに関する理解が高められると思われます。