マネージドサービス部 佐竹です。
AWS re:Inforce 2025 に現地参加してきましたので、そのログを順番に記述しています。
- はじめに
- GRC301 Best practices for managing governance, risk, and compliance globally 解説
- 関連記事等
- まとめ
はじめに
2025年6月16日から18日にかけて、ペンシルベニア州フィラデルフィアで AWS のセキュリティに特化したカンファレンス「AWS re:Inforce 2025」が開催されました。
参加したセッションのレポートを「1日のまとめ」に書いていこうとしたらあまりにも文章量が増えすぎてしまったので小分けにしています。
本ブログは「【AWS re:Inforce 2025】現地参加レポート 3日目 6月18日(火) 佐竹版」より GRC301 Best practices for managing governance, risk, and compliance globally のセッションレポート（解説）です。
私の感想やコメントは解説の邪魔になると感じたので「脚注」として記載しています。ただし大きく補足が必要な場面では別途いくつか補足を記載しています。
GRC301 Best practices for managing governance, risk, and compliance globally 解説
翻訳すると「グローバルにガバナンス、リスク、コンプライアンスを管理するためのベストプラクティス」となります。
本セッションは、クラウド利用がスケールする現代において、企業がいかにして効果的なガバナンス、リスク管理、そしてコンプライアンス（3つ合わせて"GRC"と省略されています）を大規模に実現するか、というテーマを深掘りするものです。
特に、Meta 社のクラウドジャーニーを実例として、AWS Control Tower や AWS Organizations を用いたセキュアな基盤の構築方法、AWS Config や AWS CloudTrail を活用した効果的なガバナンスのアーキテクチャパターンが紹介されました。
なぜ今、GRC は「オプション」ではなく「必須」か？（課題）
かつてクラウド利用がテスト環境などに限定されていた時代*1、GRC は「オプション」と見なされることもありました。しかし、今や状況は一変しています。
「2025年までに、新規デジタルワークロードの 95% がクラウドネイティブプラットフォームにデプロイされるようになり、これは 2021年の 30% から増加する見込みです。」
ガートナーリサーチ（2023年クラウドセキュリティ展望レポート）
このように、基幹システムを含む様々なワークロードがクラウドに移行する中、GRC はビジネス継続のための必須要件となっています。そして「コンプライアンス違反によって生じるコスト」は、「コンプライアンスを維持するためのコスト」を上回ることさえあるということです。
「統合されたクラウド GRC ソリューションを導入した組織は、セキュリティインシデントが 45% 少なく、コンプライアンスコストを年間平均で 350万ドル節約しています。」
IBM セキュリティレポート（2023年）
適切に GRC を実装することで、セキュリティインシデントを減らし、不要なコストの発生も防げます。
ですが、GRC の実装には多くの課題が伴います。
- GRC の一般的な課題
- 新規・更新された規制要件
- データプライバシー
- データ主権
- リスク管理コスト
- データ耐障害性
絶えず変化する規制環境、生成 AI の台頭によるデータ活用の増加とそれに伴うプライバシーやデータ主権の問題、そしてリスク管理とコストのバランス。これらの複雑な課題に、組織は適応し続けなければなりません*2。
GRC 実現の土台：人とプロセスの重要性
効果的な GRC は、ツールやテクノロジーだけで実現するものではありません。その土台には「人」と「プロセス」が存在します。セッションでは、3つの重要なステップが強調されました。
目的を明確にする (Determine your Why):
何よりもまず、自社のビジネス目標と GRC の取り組みを連携させることが重要です。例えば、決済処理システムを持つモバイルアプリを開発する場合、PCI DSS のような金融規制への準拠が必須となります。
誰が機密データにアクセスできるのか、どのデータをどう保護するのか。ビジネスの文脈からリスクを洗い出し、GRC の明確なゴールを設定することが最初のステップです。既存プロセスを評価する (Assess your existing processes):
ゼロから始める必要はありません。多くの組織には、既に何らかの GRC プロセスが存在するはずです。
現在地を正確に把握し、そこからどのように進化させていくかを考えます。これは革命ではなく「進化」であるべきです。ステークホルダーと連携する (Align with your stakeholders):
GRC はセキュリティチームだけのものではありません。GRC プログラムの推進には、リーダー層の理解と支援が不可欠です。同時に、数百、数千に及ぶ開発チームも重要なステークホルダーです。
彼らが扱うアプリケーションは、それぞれ異なるリソース、構成、データセット、そしてコンプライアンス要件を持っています。開発者一人ひとりが、自らのアプリケーションに対する GRC 要件を正しく認識し、実践できるような仕組み作りが求められます。
Meta が実践する大規模 GRC
セッションのハイライトの一つが、Meta 社による"超"大規模環境での GRC 実践例です。
月間 40億人のアクティブユーザーを抱え、自社で世界最大級のデータセンターを運営する Meta 社が、なぜ、そしてどのように AWS を活用しているのでしょうか。
Meta が AWS を選ぶ理由
Meta 社は主に 4つの理由から AWS を活用しています。
- コンプライアンス (Compliance):
グローバルにサービスを提供する上で、各地域の法規制や基準への準拠は必須です。AWS を利用することで、これらの要件を効率的に満たすことができます。 - レイテンシー (Latency):
エンドユーザーに近い場所でサービスを提供し、遅延を最小化するために AWS のグローバルインフラが活用されます。 - 迅速な実験 (Activate faster experimentation):
200を超える AWS の豊富なサービス群は、開発者が新しい機能を迅速に開発・テスト（PoC）するための強力な武器となります。 - 専門的な能力 (Specialized capabilities):
自社のデータセンターにはない特殊なコンピュートリソースなどを補完するために AWS が利用されます*3。
Meta の GRC 戦略
Meta 社の GRC は、「何かがデプロイされる前に始まる」という思想に基づいています。全てのユースケースは、クラウドに展開される前に、財務、プライバシー、法務、ネットワークセキュリティなど、多角的なレビューを通過する必要があります。これにより、問題が発生する前にリスクを特定し、手遅れになるのを防ぎます。
1. AWS Organizations による論理的なグルーピング
1000を超える AWS アカウントを管理するため、Meta 社は AWS Organizations を駆使して、ユースケースに応じた論理的なアカウントのグルーピングを行っています。
- Meta の Organization 構造
- スケーリングのサポート
- 予防的統制
- 期待値の管理
この OU（組織単位）構造により、統制のスケーラブルな適用を可能にしています*4。
- Incident Response OU:（構成図左端）
不審なアクティビティが検出されたアカウントをこの OU に移動させ、即座にネットワークを遮断。脅威分析チームが安全に調査できる環境を確保します。 - DMZ OU:（構成図右端）
ルートユーザーの使用を許可する唯一の実験的な OU。 - Sandbox OU:
2週間で自動的に削除される一時的なアカウントを作成できる OU。これにより、開発者は安全な環境で迅速に PoC を実施できます。
補足事項①：「2週間で削除される」アカウント
「2週間で削除される」アカウントの運用は興味深いです。原文を見てみましょう。おおよそ以下の通りです。
Sandbox is very special that lets us create ephemeral accounts with higher controls, or actually low controls, but some restrictions. If an account is created in Sandbox, we make sure it's gone within two weeks. This allows us to enable our developers to do experimentation, move fast, do POCs and things like that.
サンドボックス(OU) 配下は非常に特殊で、一時的な（ephemeral*5）アカウントを作成することができます。これには高度な、いや実際には緩い統制が適用されますが、いくつかの制限があります。サンドボックスでアカウントが作成された場合、私たちはそれが2週間以内に削除されるようにしています。これにより、私たちの開発者は実験を行ったり、迅速に動いたり、PoC（概念実証）などを実行したりすることが可能になります。
it's gone within two weeks と述べられていますが、ephemeral accounts と相まって、2週間で消える運命にあるアカウントという意味かと受け取れます。
2. ガードレールの実装
Meta 社は、codified policies（コード化されたポリシー）によって様々なガードレールを実装しています。
- サービスゲーティング (Service Gating):
SCP（サービスコントロールポリシー）を利用し、ユースケースごとに承認されていないサービスの利用を禁止します。例えば、S3 の使用が承認されていないアカウントでは、S3 の API コールが一切できなくなります。 - Infrastructure as Code (IaC) の徹底:
インフラの100%を Terraform 経由でデプロイすることを目指しています。※詳しくは後述 - データ境界 (Data Perimeter):
新機能である RCP（リソースコントロールポリシー）も活用し、機密データ周辺のデータ境界を定義しています。 - ユーザーエクスペリエンスへの配慮:
SCP によってアクセスが拒否された場合、開発者はただ「Access Denied」というメッセージを受け取るだけです。これでは開発体験が損なわれます。
Meta 社では、CloudTrail ログをリアルタイムで監視し、ポリシーによってアクセスが拒否された場合は即座に「なぜ拒否されたのか」「どうすればよいのか」をユーザーに通知するカスタムの仕組みを構築しています*6。これにより、厳しい統制と優れた開発者体験を両立させています。
3. Infrastructure as Code (IaC) の徹底
先の通り、Meta 社では、インフラの 100% を Terraform によってコードで管理することを目指しています。
- すべてのインフラ変更はコードレビューを経由すべき
- Cloud CLI は Terraform のラッパーツール
- ユーザーのためのセキュアバイデフォルトな整備済み経路（Meta Instance, Managed EKS, S3, VPC）
- TFLints/TFComply（コード分析の実行、危険なリソース設定のブロック）*7
Terraform を直接使わせるのではなく、Cloud CLI という内製のラッパーツールを提供し、全ての変更がコードレビューを通過するように強制しています。
さらに、S3 や EKS といった頻繁に利用されるリソースについては、セキュリティ設定を抽象化した「セキュアバイデフォルト」なモジュールを提供。開発者はこのモジュールを使うだけで、セキュリティのベストプラクティスに準拠したインフラを簡単に構築できます。
4. 可視性の確保
膨大なログを収集・分析し、環境全体の可視性を確保するためのアーキテクチャも構築されています。
GuardDuty, AWS Config, CloudTrail, CloudWatch など、様々な AWS サービスからログを集約し、分析のために自社のインフラへ転送しています。この仕組みにより、1日に数十億件のログを処理し、セキュリティ分析やデータ駆動での意思決定に役立てています。
特に AWS Config は、全てのアカウント・リージョンで有効化されており、リソースのスナップショットを収集しています。これにより、「どのリソースが最も使われているか（どのモジュールを開発すべきか）」といったインベントリ管理や、非準拠リソースの検出に活用されています。
Wiz に関しても同様です。Wiz は Meta 社が最近構築したサードパーティの統合ツールです。我々はコンピュートリソース上で Wiz のセンサーを活用し、Wiz のアウトポスト*8も利用しています。
これにより、我々のセキュリティチームはセキュリティインシデントのトリアージを行い、常にインフラを監視し、セキュリティインシデントを管理可能な状態に保つことができます。これによって我々は大規模なセキュリティを実現できているのです。
統制戦略の柱
Meta 社の事例からもわかるように、効果的な GRC の鍵は「コントロール（統制）」にあります。AWS は、GRC の様々な側面をカバーする広範なサービスを提供しています。
これら多数のサービスを効果的に活用するための考え方が、ガバナンスコントロールです。
セッションでは、これらのコントロールが3つのカテゴリに分類され、解説されました。
- 予防的コントロール (Preventive Controls):
セキュリティポリシー違反につながるアクションを許可しない*9 - 事前対応的コントロール (Proactive Controls):
リソースがプロビジョニングされる前にスキャンし、準拠していない場合はプロビジョニングをブロックする - 発見的コントロール (Detective Controls):
定義されたセキュリティポリシーに違反するリソースを検出する
これら 3つのコントロールを適切に組み合わせることが、堅牢な GRC 体制の構築につながります。
補足事項②：Types of security controls について
AWS のドキュメントには以下の4つが紹介されています。
- 予防的コントロール — イベントの発生を予防するように設計されたコントロールです。
- プロアクティブコントロール — 規制に準拠していないリソースが作成されるのを防止するように設計されたコントロールです。
- 検出的コントロール - イベントが発生したときに、検出、ログ記録、警告を行うように設計されたコントロールです。
- レスポンシブコントロール - 有害事象や、セキュリティ上の基準線からの逸脱の、修復を早めるように設計されたコントロールです。
Meta 社の実例では、4つ目の「レスポンシブコントロール」がない状態ですが、セキュリティのコントロールは「予防的コントロール」と「発見的コントロール」の2つに大別されるという認識で基本的に問題ありません。Meta 社は「シフトレフト」に倒しているという認識を持ちました。
補足はここまでです。
予防的コントロール (Preventive Controls)
「違反を未然に防ぐ」最も強力なコントロールです。ポリシー違反となるようなアクションの実行そのものを不可能にします。これは、AWS Organizations のポリシー機能によって実装されます。
サービスコントロールポリシー (SCP):
組織内のアイデンティティ（プリンシパル）が実行できる最大の権限を設定します。IAM ポリシーに似ていますが、権限を付与するのではなく、「許可される操作の上限」を定めるガードレールです。例えば、「特定のリージョン以外でのリソース作成を禁止する」「許可されたインスタンスタイプ以外の EC2 起動を禁止する」といった絶対的な境界を強制します。
リソースコントロールポリシー (RCP):
組織内のリソースに対して実行できる操作を制御します。SCP が「誰が」に焦点を当てるのに対し、RCP は「何に*10」焦点を当てます。データ境界（Data Perimeter）のシナリオで特に有効で、「組織内のアイデンティティからしかアクセスを許可しない」「特定の VPC 内からのアクセスしか許可しない」といった設定が可能です*11。
宣言的ポリシー (Declarative Policies):
特定のサービスリソースの設定値を宣言し、その状態を強制します。例えば、「全ての EBS スナップショットはパブリック共有をブロックする」と宣言すれば、AWS がその設定を組織全体で強制し、変更を許しません*12。
ここで念のため簡単に SCP と RCP の使い分けについて記載します。この 2つのポリシーは、どちらか一方を使うのではなく、組み合わせて利用することで真価を発揮します。
- RCP (リソースコントロールポリシー)
- 組織内のリソースに対する一貫したアクセス制御を強制する
- ユースケース：
- 外部アイデンティティによるリソースへのアクセスを防止する
- Confused Deputy 問題*13を強制的に制御する
- 機密リソースにコントロールを適用する
- SCP (サービスコントロールポリシー)
- 組織内のプリンシパルに対する一貫したアクセス制御を強制する
- ユースケース：
- 自社のアイデンティティが外部リソースにアクセスするのを防止する
- 開発者が使用できるサービスやリージョンを定義する
- クラウドプラットフォームリソースを保護する
簡単に言えば、RCP は「内向きの矢印」で、組織内のリソースを外部から守ります。一方、SCP は「外向きの矢印」を制御でき、組織内のアイデンティティが外部の不正なリソースにアクセスすることを防ぎます*14。この 2つを組み合わせることで、強固なデータ境界が完成します。
事前対応的コントロール (Proactive Controls)
「デプロイ前に違反をチェックする」コントロールです。Terraform や CloudFormation といった IaC パイプラインに組み込み、ポリシーに準拠していないリソース構成がデプロイされるのをブロックします。いわゆる「シフトレフト」を実現するアプローチです。
この例では、CloudFormation Hooks を利用しています。暗号化が有効になっていない S3 バケットを作成しようとすると、フックがそれを検知し、デプロイは失敗します。開発者は適切なエラーメッセージを受け取り、テンプレートを修正してから再デプロイすることになります。
発見的コントロール (Detective Controls)
「デプロイ後の違反を検出する」コントロールです。既存の環境を継続的に監査し、ポリシー違反を検出して通知します。
予防的コントロールや事前対応的コントロールを導入する前に、まず発見的コントロールで現状を把握し、既存の違反を修正するといった使い方も有効です。また、他のコントロールと組み合わせることで、多層防御の二次的な防衛ラインとしても機能します。
これは AWS Config ルールによって実装されます。AWS Config はリソースの構成変更を常に記録しており、その変更が AWS Config ルール（ポリシー）に違反していないかを評価します。違反が検出されると、リソースは「非準拠」としてマークされ、CloudWatch Events や SNS を通じてアラートを発報できます。
統制の簡素化のための AWS Control Tower
これら 3種類のコントロールを個別に実装・管理するのは大変です。そこで役立つのが AWS Control Tower です。
AWS Control Tower は、AWS のベストプラクティスに基づいた 750以上の「マネージドコントロール」のカタログを提供しています。
ユーザーはカタログから必要なコントロールを検索し、API を通じて組織内の OU に簡単に展開できます。これにより、GRC 目標を達成するための統制実装が大幅に簡素化されます。
コントロール戦略の要点は、これら 3つのタイプ（予防的、事前対応的、発見的）の特性を理解し、IT 管理者、開発者、コンプライアンス担当者といったそれぞれの役割とニーズに応じて、最適なものを選択・組み合わせていくことにあります。
スケールするデータ保護
最後のテーマは、GRC の根幹をなす「データ」そのものの保護、すなわちデータレジリエンスです。
指数関数的に増大するデータとその価値
現代においてデータは「新しい石油」と称され、その価値は計り知れません。しかし、そのデータ量は指数関数的に増大しています。
- データには価値がある
- データには保護、回復力、ガバナンスが必要
- データは増大している
- エクサバイト規模でのデータ保護と回復力（が必要になる）
- 世界のデータ量は 2028年までに 594 ゼタバイトに増加する見込みである
- エクサバイト規模でのデータ保護と回復力（が必要になる）
1ゼタバイトは 1兆ギガバイトです。この爆発的な増加は、データ保護をこれまで以上に困難な課題にしています。
マルチアカウント環境で、数千のアプリケーションにまたがるデータを、いかにして標準化し、保護し、コンプライアンス要件を満たしていくか。その答えがバックアップ戦略にあります。
Well-Architected なバックアップ戦略
堅牢なバックアップ戦略を構築するための 5つの柱が以下です。
- RTO と RPO を理解する:
アプリケーションごとに目標復旧時間（RTO）と目標復旧時点（RPO）を定義し、それに応じてバックアップ計画をグループ化します。 - 最小権限ポリシーを実装する:
バックアップデータへのアクセスも最小権限に。誰がアクセスできるかを厳密に管理します。 - バックアップ保持期間を決定する:
アプリケーションのユースケースとコンプライアンス要件に基づき、適切な保持期間を設定します。 - 暗号化戦略を有効にする:
バックアップデータそのものも暗号化し、保護を徹底します。 - 継続的なテストと監査で検証する:
設定したポリシーが期待通りに機能しているか、定期的にテストし、監査レポートを作成して検証します。
AWS Backup による一元的なバックアップ管理
これらの戦略を AWS 上で実現する中核サービスが AWS Backup です。
AWS Backup は、EC2 やコンテナ、オンプレミスの VMware といったコンピュート、S3 や EFS といったストレージ、そして DynamoDB や RDS などのデータベースまで、多岐にわたるサービスをサポートしています。
また、組織全体にまたがるバックアップ計画を一元的に作成・管理できます。タグベースのポリシー適用により、prod タグが付いたリソースには本番用のバックアップポリシーを、test タグにはテスト用のポリシーを、といった柔軟な運用が可能です。
加えて、Backup Audit Manager を使えば、「重要なリソースは全てバックアップされているか？」「バックアップは暗号化されているか？」といったコンプライアンス要件を継続的に評価し、レポートを作成できます。
論理エアギャップと新機能「多者承認」
しかし、もし攻撃者が管理アカウント（管理アカウントとは AWS Organizations における Delegated Admin のことと考えられます）へのアクセス権を奪ってしまったらどうなるでしょうか。
バックアップデータが削除・破壊されるリスクがあります。この最悪のシナリオに対する最後の砦が、AWS Backup の論理エアギャップ機能です。
- AWS Backup logically air gapped vault
- 不変性 (IMMUTABILITY): 作成時にコンプライアンスモードのボールトロックが適用される
- データ分離 (DATA ISOLATION): AWS サービス所有のキーで保護を強化
- 迅速な RTO (FASTER RTO): AWS RAM 共有を使用してアカウント間で直接リストアして回復
AWS Backup 論理エアギャップボールト (logically air-gapped vault) は、バックアップデータを顧客のアカウントから物理的・論理的に隔離された AWS サービス自身のアカウント内に保管します。これにより、万が一顧客の管理アカウントが侵害されても、バックアップデータは安全に保護されます。
さらに、re:Inforce 2025 で発表された最新機能が、このボールトと多者承認（Multi-party approval）の統合です。
これは管理アカウントが侵害されアクセス不能になった最悪の事態でもバックアップを回復するための機能です。
事前に指定した信頼できるチーム（4人または5人のチーム）が、別のクリーンなアカウントからのデータ回復リクエストを承認します。これにより、侵害されたアカウントの認証情報とは完全に独立した、安全な回復経路を確保します。
補足事項③：Multi-party approval に関するユースケースの追記
もし攻撃者によって AWS Backup の管理アカウントが奪取されたとします。攻撃者はボールトの中身を削除できなくても、ボールトへのアクセス経路を絶ったり、正当な管理者を締め出したりすることが可能です。その結果、バックアップデータは安全に存在しているにもかかわらず、誰にも取り出せない「塩漬け」状態になってしまう可能性がありました。
上記のようにアカウントが侵害され、自力でアクセスできなくなった場合、唯一の復旧手段は AWS サポートに連絡し、本人確認などを経てアカウントを復旧してもらうという手法しか残されていませんでした。このプロセスは、セキュリティを確保するために慎重に行われるため、非常に時間がかかりました。その間、企業はシステムを復旧できず、ビジネスが完全に停止してしまうというリスクを抱えていました。攻撃者が時間を稼いでいる間に、事業継続が困難になる可能性がありました。
本アップデートにより、独自の承認チームに、AWS Organizations アカウント外のアカウントも含め、あらゆるアカウントからのボールト共有を承認するよう依頼できるようになりました。承認されると、バックアップへの承認されたアクセスが許可され、復旧プロセスを素早く開始できます。簡単にフローを見てみましょう。
- 復旧担当者は「乗っ取られたAアカウントのバックアップを、安全なBアカウントで使えるようにしてください」という共有リクエストを出す。
- 共有リクエストが出されると、承認チームのメンバー全員に通知が飛ぶ。
- 承認チームはその通知を受け取り、専用の「承認ポータル」にログイン。リクエストの内容を確認し、「これは正当な緊急事態だ」と判断したら「承認」ボタンを押す。
- 規定の人数（例：5人中3人）に承認されると、システムが自動的にバックアップへのアクセスを許可する。
- 復旧担当者は、リクエストの許可が下りた後、安全なBアカウントから、乗っ取られたAアカウントのバックアップデータが見えるようになるため作業が開始できるようになる。
結論
結論として、SCP、RCP、CloudFormation 等を利用した様々なガードレール・コントロールをレビューし、独自のカスタムガバナンスポリシーを構築することが推奨されます。
データレジリエンスのためには、アプリケーション固有のバックアップ戦略を策定し、論理的エアギャップボールトや新機能の多者承認といった高度な機能を活用すべきです。最後に、GRC への取り組みの出発点として、AWS Control Tower 内のマネージドコントロールを検討してみてください。
関連記事等
セッションの動画
この概要を読んで興味が出た方は YouTube に既に動画がアップロードされているので是非ご覧ください。
AWS Backup、論理エアギャップボールトのための新たなマルチパーティ承認を追加
NIS321 セッションレポート
なお、Meta 社の事例といえば、以下 NIS321 の LT でも紹介されていますので、Meta つながりでよろしければ合わせて以下のブログ記事もご覧ください。
まとめ
本セッションは、クラウドを大規模に利用するすべての企業にとって避けて通れない GRC という課題に対し、Meta 社の実例を踏まえながら実践的な道筋を示したものでした。
- Meta 社の事例は、AWS Organizations による論理的なアカウント管理、SCP とカスタム通知を組み合わせた「体験を損なわない予防的統制」、そしてセキュアバイデフォルトな IaC モジュールの提供など、大規模環境における GRC の具体的な実践方法を示しています。
- 「予防的」「事前対応的」「発見的」という3つのコントロールタイプを理解し、SCP や RCP、CloudFormation Hooks、AWS Config などを適切に組み合わせることが、堅牢なガードレールを構築する鍵となります。
- データ保護の最終防衛線として、AWS Backup の「論理的エアギャップボールト」でバックアップを隔離し、さらに新機能「多者承認」を組み合わせることで、管理アカウントが侵害された最悪のシナリオからもデータを回復する道筋が示されました。
- 効果的な GRC は、単一のツールではなく、人とプロセスを土台とした多層的な戦略です。本セッションで示されたアプローチを参考にしつつ、AWS Control Tower が提供するマネージドコントロールを活用することが、その第一歩を大きく簡素化することでしょう。
本セッションは AWS re:Inforce 2025 で参加した最後のセッションになりました。AWS Organizations に関するセッションということでつい長文になってしまいましたが、何かの参考になれば幸いです。
では、またお会いしましょう。
*1:これはいわゆる「ハイブリッドアーキテクチャ」のことです。オンプレミス環境とクラウドを合わせて利用する方法で、特に AWS が日本で活用されはじめた当初は、本番ワークロードはオンプレミス、検証用途でクラウドという棲み分けが代表的な使われ方でした。
*2:まさに「セキュリティは運用と維持が最も重要」と言ったところです。
*3:個人的にはこの戦略には「へぇ！」と驚かされました。使い分けが素晴らしいです。
*4:「AWSのホワイトペーパーから学ぶ AWS Organizations における推奨 OU 構成」で記述したベストプラクティスとは少々設計が異なる点が興味深いです https://blog.serverworks.co.jp/recommended-ous
*5:ephemeral は「つかの間の、一時的な、短命の」といった意味を持つ形容詞。IT の文脈では、一時的に存在し、その後消滅（削除）されることを前提としたリソース（コンテナ、インスタンス、アカウントなど）を指します。
*6:これは凄すぎます。Next Step を常に案内する仕組みは真似しようとしてもなかなか難しい取り組みです。
*7:セッションのスライドでは TFLints と表記されていましたが、ツールの正式名称は TFLint https://github.com/terraform-linters/tflint
*8:AWS Outposts のように、Wiz アウトポストはセキュリティやコンプライアンス上の理由でデータを外部に出せない組織向けの機能
*9:私はこれを日本語で端的に「禁止」と説明することが多いです
*10:つまりリソースに対して
*11:RCP は2024年11月にリリースされました https://aws.amazon.com/jp/blogs/news/introducing-resource-control-policies-rcps-a-new-authorization-policy/
*12:2024年12月に発表された比較的新しいポリシーです。各 AWS アカウントの「EC2 のデータ保護とセキュリティ」等で設定が可能な値のデフォルトを組織で管理できるような機能です https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_declarative.html
*13:混乱する代理問題 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/confused-deputy.html
*14:SCP は外向きではあるものの、プリンシパルベースでなんでも Deny することができます。特定の IAM Role を削除させたくない、なども可能です。他には IAM User の Credentials を払い出すことを禁止もできます。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
