OU」が追加された件について記載します。(構成例)まとめ及び所感はじめに2021年8月に、学習を目的として以下のブログを記載しました。ホワイトペーパーを元にしたブログです。OUs」という項目がありました。accounts」という名称となって引き続きホワイトペーパーに掲載されています。ドキュメントに掲載されていた画像をお借りして貼り付けていたものがありました。それが以下の画像です。構成は、ブログ記載当時のものです。これが今現在は、以下のものに差し替わっています。2024年6月11日頃に本ホワイトペーパーにアップデートがあったようでした。OU」が追加されました。赤枠は私が説明のために用意したものです。その数が10から11に増えることとなりました。OU」について解説するブログとなっております。関する用語説明などは省いております。用語説明については、以前のブログを合わせてご覧ください。作成すべきアカウントと委任すべきサービスが記載されるようになりました。OU」で顕著であり、記載されているボリュームも大幅に増えています。最初に「バックアップアカウント」を作成するように記載がされています。今回のブログに関わる内容のため、バックアップアカウントについて少し掘り下げてみます。バックアップアカウント以下がホワイトペーパーのバックアップアカウントに関する記載箇所の日本語訳です。バックアップアカウントは、バックアップと災害復旧管理のための専用の一元化されたハブとして機能します。アカウント全体でバックアップポリシーを調整、監視、および適用するための統合プラットフォームを提供します。バックアッププロセスを中央アカウント(補足:つまりバックアップアカウント)に統合することで、組織はいくつかのメリットを実現できます。具体的には、各メンバーアカウントで個別にバックアップ設定を構成および維持する必要がなくなるため、バックアップ管理が簡素化され、運用効率が向上し、エラーの可能性が減ります。インフラストラクチャ全体で一貫性のある包括的なデータ保護が保証されます。このアプローチでは、バックアップと復旧アクティビティの集中的な監査とレポートが可能になり、コンプライアンスとガバナンスの取り組みも強化され、データ保護メトリックの追跡とコンプライアンスのために必要な記録の維持が容易になります。バックアップアカウントについてはここまでとなります。OU」は一読の価値がありますので、是非合わせてご覧ください。OU)それでは本題です。構成」と同様に、ホワイトペーパーを翻訳しながらベストプラクティスをご紹介します。公式ドキュメントは以下の通りです。原文を読まれたい方は以下よりご確認ください。docs.aws.amazon.comなお「補足:」から始まる文章は私が補足説明のために追記した文章であり、原文には存在しません。太字による強調は私が独自に付け加えたものとなります。組織が固有のワークロード要件に基づき、データの分離及びデータレジデンシー制御を必要とする高度なユースケースのトピックです。内のバックアップアカウントを使用して実装できます。チームが「クロスアカウントでの災害復旧戦略」の実装を支援することを目的としています。ワークロードリソースが存在しません。これにより、組織を保護し、ランサムウェアなどの深刻な災害からの復旧を可能にする「セキュアデータバンカー」が作成されます。セキュアデータバンカーには、ワークロードの災害復旧データが利用できないか、信頼できない状態になってしまった、もしくは破壊されてしまったような場合にのみアクセスを可能とする必要があります。ワークロードの通常の災害復旧計画(補足:通常のバックアップやその取得のための設定)に代わるものではありません。組織の回復力を強化することを目的とした追加の保護レイヤーです。Cloud」を参照してください。使用することでコンプライアンスを維持するのに役立ちます。Outposts」ブログを参照してください。「セキュアデータバンカー」とするためには、データが侵害されないようにアクセスを厳しく制限する必要があります。アクセスできないようにします。サービス、リソース、およびアクションのみが許可されるようにして制御を行います。バックアップポリシーが変更されないようにします。バックアップが中断されていないことを確認するために、監視通知を実装します。監視に関するドキュメントを参照してください。使用し、最小保持期間を14日以上とする必要があります。バックアップポリシーのコンプライアンスを確保するために、定期的にバックアップを監査します。ドキュメントを参照してください。主軸になっており、これは先にご紹介した「バックアップアカウント」に通ずるものがあります。環境がプロダクションスターター組織ガイダンスに則っている場合を考えます。3つのワークロードがあり、それぞれに個別のテストアカウントと本番アカウントがあります。データには機密性がなく、規制されていません。データは機密性が高く、規制されているため、他のワークロードデータからこれを分離する必要があります。頭文字をとったもの)アカウントに保持できます。データは高度に機密性があり規制されているため、テストデータとプロダクションデータを別々のアカウント(bc-workload-c-test-dataとbc-workload-c-prod-data)に分離します。一部の企業では、規制やコンプライアンスの必要性に関係なく、セキュリティ姿勢を強化するために各ワークロードのデータを個別のアカウントに分離することを選択しています。中でもそのセキュリティレベルに応じて適切にアカウントを分離する、という設計について記載されています。以上でホワイトペーパーからの引用及び翻訳を終了いたします。OU」について記載しました。リリースされたと認識しております。文中、太字で強調させて頂きましたが「ランサムウェアなどの深刻な災害からの復旧を可能にする」というワードがありました。ここにランサムウェアという単語が明記されていることは注目に値すると思います。もって入口を封鎖する重要性は多層防御の観点からも重要ですが、ランサムウェア(マルウェア)の脅威は感染後のラテラルムーブメント(水平展開)にあります。侵入された後、ランサムウェアが横展開されてしまい、バックアップを含めて全てのデータの正常性の確認が取れなくなってしまった、という事例は何度も耳にしたことがあります。そのような事態を発生させないためにも、通常のバックアップ戦略(災害復旧計画)に加えて、より強固な「セキュアデータバンカー」の作成が今後望まれるようになってくると思われます。概念だけでもご理解頂ければと思います。アカウントのセキュリティ向上の一助となれば幸いです。エンジニアブログの記事一覧はコチラマネージドサービス部所属。2010年1月からAWSを利用してきています。AWSのコスト削減、最適化を得意としています。2009-引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。