マネージドサービス部 佐竹です。
本ブログでは、AWS のホワイトペーパーに新しい推奨 OU として「Business Continuity OU」が追加された件について記載します。
はじめに
2021年8月に、学習を目的として以下のブログを記載しました。
この「AWSのホワイトペーパーから学ぶ AWS Organizations における推奨 OU 構成」は2021年6月2日にアナウンスされた「Organizing Your AWS Environment Using Multiple Accounts」という新しい AWS のホワイトペーパーを元にしたブログです。
当時はこのホワイトペーパーに「Recommended OUs」という項目がありました。
現在はこれが「Recommended OUs and accounts」という名称となって引き続きホワイトペーパーに掲載されています。
2024年6月 ホワイトペーパーにアップデートがありました
先程の私のブログ記事には AWS ドキュメントに掲載されていた画像をお借りして貼り付けていたものがありました。それが以下の画像です。
上記画像の推奨 OU 構成は、ブログ記載当時のものです。
これが今現在は、以下のものに差し替わっています。2024年6月11日頃に本ホワイトペーパーにアップデートがあったようでした。
右端に「Business Continuity OU」が追加されました。赤枠は私が説明のために用意したものです。
このため、推奨 OU はその数が10から11に増えることとなりました。
- Security OU
- Infrastructure OU
- Sandbox OU
- Workloads OU
- Policy Staging OU
- Suspended OU
- Individual Business Users OU
- Exceptions OU
- Deployments OU
- Transitional OU
- Business Continuity OU (←今回新規に追加された OU)
ということで、本ブログは追加された「Business Continuity OU」について解説するブログとなっております。
また本ブログでは、AWS Organizations に関する用語説明などは省いております。用語説明については、以前のブログを合わせてご覧ください。
アップデートに関して更なる情報
ページの名称が「Recommended OUs and accounts」と変更されたことで、各 OU には作成すべきアカウントと委任すべきサービスが記載されるようになりました。
特にこれは「Security OU」と「Infrastructure OU」で顕著であり、記載されているボリュームも大幅に増えています。
例えば、Infrastructure OU には最初に「バックアップアカウント」を作成するように記載がされています。
今回のブログに関わる内容のため、バックアップアカウントについて少し掘り下げてみます。
バックアップアカウント
以下がホワイトペーパーのバックアップアカウントに関する記載箇所の日本語訳です。
バックアップアカウントは、バックアップと災害復旧管理のための専用の一元化されたハブとして機能します。AWS 組織内の AWS アカウント全体でバックアップポリシーを調整、監視、および適用するための統合プラットフォームを提供します。
バックアッププロセスを中央アカウント（補足：つまりバックアップアカウント）に統合することで、組織はいくつかのメリットを実現できます。
具体的には、各メンバーアカウントで個別にバックアップ設定を構成および維持する必要がなくなるため、バックアップ管理が簡素化され、運用効率が向上し、エラーの可能性が減ります。使用中の特定の AWS サービスとリソースに関係なく、AWS インフラストラクチャ全体で一貫性のある包括的なデータ保護が保証されます。このアプローチでは、バックアップと復旧アクティビティの集中的な監査とレポートが可能になり、コンプライアンスとガバナンスの取り組みも強化され、データ保護メトリックの追跡とコンプライアンスのために必要な記録の維持が容易になります。
一旦バックアップアカウントについてはここまでとなります。
ということで、大幅に追記がされた「Security OU」と「Infrastructure OU」は一読の価値がありますので、是非合わせてご覧ください。
Business Continuity OU (ビジネス継続性 OU)
それでは本題です。「AWSのホワイトペーパーから学ぶ AWS Organizations における推奨 OU 構成」と同様に、ホワイトペーパーを翻訳しながらベストプラクティスをご紹介します。
元となる AWS 公式ドキュメントは以下の通りです。原文を読まれたい方は以下よりご確認ください。
なお「補足：」から始まる文章は私が補足説明のために追記した文章であり、原文には存在しません。また太字による強調は私が独自に付け加えたものとなります。
ではこれより開始します。
[Note] ビジネス継続性 OU は、AWS 組織が固有のワークロード要件に基づき、データの分離及びデータレジデンシー制御を必要とする高度なユースケースのトピックです。一般的には、ほとんどのクロスアカウント災害復旧戦略は、インフラストラクチャ OU 内のバックアップアカウントを使用して実装できます。
ビジネス継続性 OU は、チームが「クロスアカウントでの災害復旧戦略」の実装を支援することを目的としています。データは可能な限りエアギャップに近いもので*1、OU にはワークロードリソースが存在しません。これにより、組織を保護し、ランサムウェアなどの深刻な災害からの復旧を可能にする「セキュアデータバンカー」が作成されます。セキュアデータバンカーには、ワークロードの災害復旧データが利用できないか、信頼できない状態になってしまった、もしくは破壊されてしまったような場合にのみアクセスを可能とする必要があります。
ビジネス継続性 OU は、ワークロードの通常の災害復旧計画（補足：通常のバックアップやその取得のための設定）に代わるものではありません。組織の回復力を強化することを目的とした追加の保護レイヤーです。ワークロードの災害復旧に関する一般的な推奨事項については、「Disaster Recovery of Workloads on AWS: Recovery in the Cloud」を参照してください。
データレジデンシー要件があり、単一のAWSリージョンしか利用できない地理的地域にある組織に対しては、AWS Outposts を使用することでコンプライアンスを維持するのに役立ちます。詳細は「Ensure Workload Resiliency and Comply with Data Residency Requirements with AWS Outposts」ブログを参照してください。
Controls （コントロール）
ビジネス継続性 OU を「セキュアデータバンカー」とするためには、データが侵害されないようにアクセスを厳しく制限する必要があります。
理想的には、ビジネス継続性 OU 内のデータにアクセスできるユーザーは通常の環境にアクセスできないようにし、通常の環境にアクセスできるユーザーはビジネス継続性 OU にはアクセスできないようにします。本 OU と承認されたユーザーに SCP と IAM の組み合わせを適用することで、必要な AWS サービス、リソース、およびアクションのみが許可されるようにして制御を行います。
Additional consideration （追加の考慮事項）
- バックアップ管理者ロールに制限を設け、ビジネス継続性 OU のバックアップポリシーが変更されないようにします。
- バックアップが中断されていないことを確認するために、監視通知を実装します。AWS Backup 監視に関するドキュメントを参照してください。
- すべてのバックアップボルトで、コンプライアンスモードでの AWS Backup Vault Lock を使用し、最小保持期間を14日以上とする必要があります。
- バックアップポリシーのコンプライアンスを確保するために、定期的にバックアップを監査します。AWS Backup Audit Manager のドキュメントを参照してください。
補足：この考慮事項を見ればわかる通りなのですが、AWS Backup が主軸になっており、これは先にご紹介した「バックアップアカウント」に通ずるものがあります。
Example structures （構成例）
例として、Rainbows 社のスターター AWS 環境がプロダクションスターター組織ガイダンスに則っている場合を考えます。Rainbows 社には A、B、C の3つのワークロードがあり、それぞれに個別のテストアカウントと本番アカウントがあります。ワークロード A と B のデータには機密性がなく、規制されていません。ただし、ワークロード C のデータは機密性が高く、規制されているため、他のワークロードデータからこれを分離する必要があります。
続く Rainbows 社のビジネス継続性 OU の例では、ワークロード A と B のデータは機密性がなく規制されていないため、同じビジネス継続性（補足：アカウント名の bc- は Business Continuity の頭文字をとったもの）アカウントに保持できます。しかし、ワークロード C のデータは高度に機密性があり規制されているため、テストデータとプロダクションデータを別々のアカウント（bc-workload-c-test-dataとbc-workload-c-prod-data）に分離します。
[Note] 一部の企業では、規制やコンプライアンスの必要性に関係なく、セキュリティ姿勢を強化するために各ワークロードのデータを個別のアカウントに分離することを選択しています。
補足：この例では、Business Continuity OU の中でもそのセキュリティレベルに応じて適切にアカウントを分離する、という設計について記載されています。
以上でホワイトペーパーからの引用及び翻訳を終了いたします。
まとめ及び所感
本ブログでは、AWS のホワイトペーパー「Organizing Your AWS Environment Using Multiple Accounts」の「Recommended OUs and accounts」において、11個目の推奨 OU として新たに追加されました「Business Continuity OU」について記載しました。
昨今、特にクラウドセキュリティについての重要性が叫ばれるなか、AWS から強いメッセージ性をもって本 Business Continuity OU (ビジネス継続性 OU) がリリースされたと認識しております。
文中、太字で強調させて頂きましたが「ランサムウェアなどの深刻な災害からの復旧を可能にする」というワードがありました。ここにランサムウェアという単語が明記されていることは注目に値すると思います。
WAF などをもって入口を封鎖する重要性は多層防御の観点からも重要ですが、ランサムウェア（マルウェア）の脅威は感染後のラテラルムーブメント（水平展開）にあります。侵入された後、ランサムウェアが横展開されてしまい、バックアップを含めて全てのデータの正常性の確認が取れなくなってしまった、という事例は何度も耳にしたことがあります。
そのような事態を発生させないためにも、通常のバックアップ戦略（災害復旧計画）に加えて、より強固な「セキュアデータバンカー」の作成が今後望まれるようになってくると思われます。将来に備えるためにもまずはこの Business Continuity OU の概念だけでもご理解頂ければと思います。
そして本ブログが貴社 AWS アカウントのセキュリティ向上の一助となれば幸いです。
では、またお会いしましょう。
*1:補足：エアギャップはそのリソースが他のネットワークから（空隙として）電気的に切断されていることを示していますが、AWS としては他のアカウントにデータを置きつつ、且つそのアカウントを Transit Gateway 等で接続せず切り離しておき、権限的にも触れなくすることで「エアギャップ」を実現するということのようです
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
