Amazon Web Services ブログ

AWS でバックアップを保護するためのセキュリティベストプラクティス Top 10

この記事は “ Top 10 security best practices for securing backups in AWS ” を翻訳したものです。

セキュリティは AWS とお客様の間で責任を共有することで実現されます。ここで、お客様は AWS で安全にバックアップを行う方法を求めています。この記事では AWS 上のバックアップデータの保全とその操作に関して、厳選したセキュリティベストプラクティスのトップ 10 を紹介します。この記事では AWS Backup サービスにおけるバックアップデータと操作に焦点を当てて紹介しますが、推奨されるセキュリティのベストプラクティスは AWS Marketplace で提供されるバックアップツールなど、他のバックアップソリューションを利用されている組織でも活用することが可能です。

セキュリティ対策は新しいリスクを軽減するために常に発展しているため、定期的にリスク評価を実施して妥当性を判断し、データに対するリスクを軽減するために何重もの対策を実施することが重要です。

#1 – バックアップ戦略を策定する

包括的なバックアップ戦略は、組織のデータ保護計画に不可欠な要素です。これにより、セキュリティイベントによって被る可能性のあるあらゆる影響に耐え、復旧し、軽減することができます。どのデータをバックアップしなければならないか、どの程度の頻度でデータをバックアップしなければならないか、バックアップとリカバリ ( = 復旧) のタスクをどのように監視するかなどを踏まえ、広範なバックアップ戦略を策定する必要があります。データのバックアップと復旧に関する包括的な戦略を策定する際には、発生する可能性のある障害とその潜在的なビジネス上の影響を初めに特定する必要があります。

お客様の目標は、許容可能な RTO (目標復旧時間) と RPO (目標復旧時点) 内でワークロードを復旧させるまたはダウンタイムを回避するような復旧戦略を計画することです。RTO とはサービスの中断から復旧までの許容可能な遅延時間であり、RPO とは最後に記録されているデータ復旧ポイントからの許容可能な時間です。継続的なバックアップ、ポイントインタイムリカバリー (PITR) 、ファイルレベルリカバリー、アプリケーションデータレベルリカバリー、ボリュームレベルリカバリー、インスタンスレベルリカバリーなどのすべてを含む粒度の細かいバックアップ戦略を検討する必要があります。

良く設計されたバックアップ戦略には ランサムウェア からリソースを保護・復旧するためのアクションが含まれており、アプリケーションやそのデータに関連した詳細な復旧要件が設定されている必要があります。例えばランサムウェアのリスクを軽減するために予防的および発見的な統制を定める一方で、セキュリティイベントが発生した際に管理者が破損されたバックアップデータから復旧しないように、クロスリージョンおよび / またはクロスアカウントにコピーして復旧するパターンについて適切な粒度で設計する必要があります。

業界によってはバックアップ戦略を策定する際に、データ保持要件の規制も考慮しなければならない場合があります。バックアップ戦略は規制の必要性を満たすために十分な保持要件(データ分類レベルおよび / またはリソースタイプごと)を考慮して設計する必要があります。

バックアップリソースとオペレーションについて、コンプライアンスプログラムの範囲に含まれるか、またはセグメント化するべきかどうかを検証するために皆さんの組織のセキュリティコンプライアンスチームに相談してください。PCI DSS Qualified Security Assessor (QSA) としての私(筆者)個人の経験では、成熟したお客様はバックアップ & リカバリをセキュリティプログラムの重要な部分として含んでいました。これにより環境全体のデータの場所を理解し、コンプライアンス範囲を適切に定義することができます。

クラウドにおける信頼性、安全性、効率性、コスト効率の高いワークロードの設計と運用を行うためのアーキテクチャのベストプラクティスについて、AWS を使用したバックアップ & リカバリのアプローチ および AWS Well-Architected Framework の Reliability Pillar を参照してください。

#2 – バックアップを DR と BCP に組み込む

ディザスタリカバリー (DR) とは災害に対する準備、対応、復旧のプロセスのことです。DR はレジリエンス戦略の重要な部分であり、災害が発生したときにワークロードがどのように対応するかに関わります。災害とは、技術的な障害、人為的な行為、または自然現象である可能性があります。事業継続計画 (BCP) は想定外の混乱時に組織が通常の事業を継続するための方法の概要を示します。

災害復旧計画は組織の事業継続計画 (BCP) のサブセットであるべきで、企業の事業継続計画に AWS Backup の手順を取り入れる必要があります。例えば、本番データに影響を与えるセキュリティイベントが発生した場合、他の AWS リージョンのバックアップデータにフェイルオーバーする災害復旧計画を呼び出す必要があるかもしれません。従業員が AWS Backup の使用方法を理解し、組織の手順と合わせて訓練していることを確認し、災害が発生した場合にサービスがほとんど中断されることなく通常の業務を継続できるようにする必要があります。

#3 – バックアップ操作の自動化

組織は企業のデータ保護ポリシーを反映するために、バックアッププランとリソース割り当てを設定する必要があります。バックアップポリシーや組織全体のバックアップ計画 について自動化して展開することで、バックアップ戦略を標準化し拡張することができます。AWS Organizations を活用し、サポートされる AWS リソース 全体でバックアップポリシーを一元的に自動化し、スケジュールされたバックアップ操作について実装、構成、管理、統制することが可能です。

デジタルトランスフォーメーションとバックアップ戦略の必須要素として Infrastructure as Code (IaC) とイベント駆動型アーキテクチャの導入を検討し、マルチアカウント環境における生産性向上とインフラ運用のガバナンスを図る必要があります。バックアップを自動化することで、時間のかかるバックアップの設定における手動のオーバーヘッドを削減し、エラーのリスクを最小限に抑え、ドリフト検出の可視性を提供し、複数の AWS ワークロードまたはアカウントにわたるバックアップポリシーのコンプライアンスを強化することができます。

バックアップポリシーをコードとして実装することにより、リソースタイプに応じた異なる要件の設定、エンタープライズデータの保護戦略の拡張、ライフサイクルルール の実装によるリカバリポイントがコールドストレージに移行するまでの期間や削除期間の指定、データ保護規制を満たしたコスト最適化を行うことが可能です。

バックアップ操作を自動化する際に AWS タグとリソース ID を使用してリソース割り当てオプションを拡張し、ビジネスクリティカルなアプリケーションのデータを保存する AWS リソースを自動的に識別して、イミュータブルバックアップを使用したデータの保護が可能です。これはアクセス権限やバックアップ計画、ポリシーなどのセキュリティコントロールの優先順位付けに役立ちます。( 訳者注:イミュータブルとは、「変更不可能な」という意味で、一度作成したら、変更を加えることができない状態のことです。)

#4 – アクセス制御の仕組みを実装する

クラウドのセキュリティについて考える際の基本戦略は、ユーザーがデータにアクセスするための適切な権限を持つことを保証する強力な ID 基盤から始める必要があります。適切な認証と認可により、セキュリティ事象のリスクを軽減することができます。責任共有モデルにおいて AWS のお客様はアクセス制御ポリシーを実装する必要があります。AWS Identity and Access Management (IAM) サービスを使用することでアクセスポリシーを大規模に作成および管理できます。

アクセス権と許可を構成する場合、バックアップデータまたは AWS Backup のボールトにアクセスする各ユーザーまたはシステムには職務を遂行するために必要な許可のみが与えられるようにし、最小権限の原則を実装する必要があります。AWS Backup を使用する際はクラウドのワークロードを保護するために バックアップボールトにアクセスポリシーを設定し、アクセス制御ポリシーを実装する必要があります。( 訳者注:ボールトとは、「金庫」という意味で、イミュータブルを実現できる環境で重要なデータをコピーして保存することです。 )

例えばアクセス制御ポリシーを実装することで、バックアッププランとオンデマンドバックアップを作成するためのアクセス権をユーザーに付与した場合でも、一度作成したリカバリーポイントを削除する権限を制限することができます。ボールトアクセスポリシーを使用すると、ビジネスニーズの必要に応じて対象のバックアップボールトを AWS アカウント、ユーザー、または IAM ロールと共有することができます。また、アクセスポリシーによって 1 つまたは複数のアカウント、あるいは AWS Organizations の組織全体とバックアップボールトを共有することができます。

ワークロードの拡張や AWS への移行に伴い、バックアップボールトやその操作に対する権限を一元的に管理する必要が生じる場合があります。その際はサービスコントロールポリシー (SCPs) を使用して、組織内のすべてのアカウントで利用可能な最大権限を一元管理します。これにより多重防衛を実現し、ユーザーが定義されたアクセス制御ガイドラインの範囲内に留まることを保証します。詳細についてはサービスコントロールポリシー (SCPs) を使用して AWS バックアップのデータと運用を保護する方法 をご覧ください。

バックアップリソースやデータへの意図しないアクセスなどのセキュリティリスクを軽減するために AWS IAM Access Analyzer を使用して AWSアカウント、ルートユーザー、IAM ユーザーまたはロール、フェデレーテッドユーザー、AWS サービス、匿名ユーザー、フィルタの作成に使用できるその他のエンティティ、などの外部のエンティティと共有されている AWS Backup IAM ロールを特定します。

#5 – バックアップデータとボールトを暗号化する

企業はデータセキュリティ戦略を向上させる必要性が増加しており、クラウドでのスケールに伴いデータ保護規制を満たすことが求められる可能性があります。暗号化方式を正しく実装することで、基本的なアクセス制御メカニズムの上にさらなる保護レイヤーを設けることができ、主要なアクセス制御ポリシーが損なった際の緩和策となります。

例えば、バックアップデータに対して過度に寛容なアクセス制御ポリシーを設定した場合においても、キー管理システムやプロセスの活用によってセキュリティイベントの影響を抑えることができます。なぜなら、データへのアクセス権と暗号化キーへのアクセス権に別々の承認メカニズムが存在し、バックアップデータは暗号文としてしか見られないようにすることが出来るからです。

AWS クラウドの暗号化を最大限に活用するためには、転送中と保存中の両方でデータを暗号化する必要があります。
転送中のデータを保護するために AWS は API コールを使用して Transport Layer Security (TLS) プロトコル を利用したネットワーク経由で AWS Backup にアクセスし、お客様とアプリケーション、Backup サービス間の暗号化を提供します。
AWS は保存時のデータを保護するためのクラウドネイティブなオプションとして、データの暗号化のために業界で採用されている強力なアルゴリズムである Advanced Encryption Standard (AES) と 256 ビット鍵長の AES-256 に対応した AWS Key Management Service (KMS)AWS CloudHSM を提供しています。お客様はデータガバナンスと規制要件を評価し、クラウドデータとバックアップボールトを暗号化するために適切なサービスを選択する必要があります。

暗号化の設定はリソースの種類とアカウント間またはリージョン間のバックアップによって異なります。一部のリソースタイプでは対象のリソースの暗号化に使用したキーとは別の暗号化キーを使用して、バックアップを暗号化する機能をサポートしています。バックアップデータやボールトデータの暗号化キーに誰がどのような条件でアクセスできるかを決定するアクセス制御を管理するため、AWS KMS が提供するポリシー言語を使用してキーに対するアクセス制御を定義する必要があります。また AWS Backup Audit Manager を使用することで、バックアップが適切に暗号化されていることを確認することができます。

詳しくはバックアップの暗号化と複製 のドキュメントを参照してください。

AWS KMS マルチリージョンキーではあるリージョンから別のリージョンにキーを複製することができます。マルチリージョンキーは暗号化されたデータを DR のために他のリージョンにコピーする必要がある場合に、暗号化管理をシンプルにするために設計されています。バックアップ戦略の一環として、マルチリージョン KMS キーの実装の必要性について評価する必要があります。

#6 – イミュータブルストレージでバックアップを保護する

イミュータブルストレージは Write Once Read Many (WORM) の状態でデータを書き込むことができます。WORM の状態ではデータは 1 度だけ書き込まれ、ストレージ媒体にコミットまたは書き込まれた後は必要に応じて何度でも読み出して使用することができます。イミュータブルストレージはデータの完全性を維持し、削除、上書き、不注意による不正アクセス、ランサムウェアの侵害などからデータを保護します。イミュータブルストレージはお客様の業務に実際に影響を与える潜在的なセキュリティイベントに対処するための効率的なメカニズムを提供します。

イミュータブルストレージは強力な SCP 制限と組み合わせることでより優れたガバナンスを実現することができます。また、法律の規定 (法的拘束など) によりイミュータブルデータへのアクセスが必要な場合には、コンプライアンスの WORM モードで使用することができます。AWS Backup Vault Lock を使用してバックアップを保護することでデータの可用性と完全性を維持することができます*。 これにより、権限のないエンティティが必要な保持期間中に顧客データやビジネスデータを消去、変更、破損することを防ぎます。AWS Backup Vault Lock は特権ユーザー (AWS アカウントのルートユーザーを含む) による削除、バックアップライフサイクル設定の変更、および定義された保持期間を変更に関する更新を防止することにより、組織のデータ保護ポリシーに対応することができます。( 訳者注: SCP 制限とは、サービスコントロールポリシー (SCP) を利用して、ルートユーザーを含む全ての IAM エンティティに対して、組織的にアクションの制限をかけることです。 )

AWS Backup Vault Lock は特にバックアップとアーカイブの完全性が厳しく求められる規制の厳しい業界で、不変性を保証しバックアップボールト内のバックアップ(復旧ポイント) を保護する防御のレイヤーを追加しています。また、意図しないアクションや悪意あるアクションが発生した場合に、復旧のためのバックアップとともにデータを保護することを可能にします。

* この機能は米国証券取引委員会 (SEC) の規則 17a-4(f) および米国商品先物取引委員会 (CFTC) の規則 17 C.F.R. 1.31(b)-(c) への準拠についてはまだ評価されていません。

#7 – バックアップの監視とアラートを実装する

バックアップジョブは失敗することがあります。バックアップ、復旧、コピーなどのジョブが失敗するとその後のプロセスに影響を与える可能性があります。最初のバックアップジョブが失敗すると、後続の他のタスクについても失敗する可能性が高くなります。このようなシナリオでは監視と通知によってイベントの経過を最もよく把握することができます。

AWS バックアップジョブを監視するために電子メールを生成する通知を設定し有効化すると、バックアップ活動を把握できるようになり、お客様自身の重要なサービスレベルアグリーメント (SLA) を確実に満たし、通常通りの監視を強化し、コンプライアンス義務を満たすのに役立ちます。AWS Backup を他の AWS サービスやチケットシステムと統合して自動調査やエスカレーションフローを実行することで、ワークロードのバックアップ監視について実装することができます。

例えば、Amazon CloudWatch を使用してメトリクスを追跡しアラームを作成してダッシュボードを表示することができます。また、Amazon EventBridge を使用した AWS Backup プロセスとイベントの監視や、AWS CloudTrail による AWS Backup API 呼び出しを時間、ソース IP、ユーザー、呼び出し元のアカウントの詳細情報とともに監視することも可能です。さらに、Amazon Simple Notification Service (Amazon SNS) でバックアップ、復旧、コピーイベントなどの AWS Backup 関連トピックにサブスクライブすることもできます。監視とアラートはバックアップジョブに対する組織的な認識を提供し、バックアップ障害に対応するのに役立ちます。

AWS Backup Audit Manager を使用するとアカウントとリージョンごとに日次のバックアップ監査レポートの証跡を自動的に生成することができます。また、自動化テンプレートとダッシュボードのセット (バックアップオブザーバーソリューション)を使用して、複数のアカウントにまたがるバックアップ監視を拡張し複数リージョンの日次の AWS バックアップレポートを集約して取得することができます

#8 – バックアップ設定の監査

組織はバックアップ頻度など定義されたコントロールに対する AWS Backup ポリシーのコンプライアンスを監査する必要があります。バックアップアクティビティを継続的かつ自動的に追跡し、レポートを自動生成してビジネス要件に準拠していないバックアップ操作またはリソースを発見し、調査する必要があります。

AWS Backup Audit Manager はビジネスコンプライアンスと規制要件に沿った、カスタマイズ可能なコンプライアンスコントロールを内蔵しています。AWS Backup Audit Managerは「Backup プランによって保護されるバックアップ・リソース」、「Backup プランの最小頻度および最小保存期間」など 5 つのバックアップガバナンスコントロールテンプレートを提供します。Infrastructure-as-Code の自動化を活用する場合 AWS Backup Audit Manager を AWS CloudFormation で使用することができます。

AWS Security Hub は AWS におけるセキュリティ状態を包括的に表示し AWS の基本的なセキュリティベストプラクティスコントロールなどのセキュリティベストプラクティスや業界標準に対して環境をチェックできるようにします。クラウド環境内で AWS Security Hub を活用する場合、 AWS におけるバックアップの保護に役立つ発見的統制が含まれている、 AWS の基本的なセキュリティベストプラクティスを有効にすることをお勧めします。AWS Backup Audit Manager と Security Hub の発見的統制はほとんどが AWS ConfigAWS マネージドルール としても利用可能です。

#9 – データ復旧機能をテストする

バックアップとして保存されたデータは必要なときに正常に復旧できることが理想的です。また、バックアップ戦略にはバックアップのテストが含まれていなければなりません。バックアップされたデータが復旧できなければ、バックアップ戦略は有効ではありません。特定の復旧ポイントを見つけ、それを復旧する機能について定期的にテストする必要があります。
AWS Backup は自動的に保護するリソースから復旧ポイントへタグをコピーしますが、復旧ポイントから復旧されたリソースへタグはコピーされません。インベントリ管理を拡張し復旧ポイントを見つけるには AWS Backup の復旧ジョブによって作成されたリソースでタグを保持し、 AWS Backup イベントをトリガーとしたタグのレプリケーションプロセスを検討する必要があります。

データ復旧ワークフローは、データ復旧パターンを確立しそれを定期的にテストすることから始めることができます。バックアップデータの復旧能力に対する信頼性を高めるために、継続的にデータ復旧テストを行うことができるシンプルで反復可能なプロセスを作成する必要があります。例えばカスタマー管理の KMS キーで暗号化された一元的な DR バックアップボールトから、別のカスタマーマネージド KMS キーで暗号化されたソースアカウントのバックアップボールトへのクロスアカウント、クロスリージョンの復旧操作をテストするパターンなどが作成できます。

このような復旧操作を頻繁にテストしない場合はクロスアカウント、クロスリージョンの操作のための KMS 暗号化に関する前提条件が正しくないことに気づくかもしれません。多くの場合に実際に機能するバックアップ復旧パターンは頻繁にテストされているパターンのみです。サポートされているバックアップリソースの種類を定期的にテストすることで、将来的に障害や重要データの損失を引き起こす可能性のある警告について早期に発見することができます。ストレージスペースの無駄を防ぎ、コストを最適化し、時間を節約するために、限定的とはなりますが実現可能な数のリカバリパスとパターンを維持することも可能です。価値のあるデータや重要なデータを失うよりもリカバリーテストが失敗したときに問題を修正する方が簡単です。

#10 – インシデント対応計画にバックアップを組み込む

セキュリティインシデント対応シミュレーション (SIRS) は現実的なシナリオの中でインシデント対応計画や手順を実践するための体系的な機会を提供するインターナルなイベントです。SIRS の活動によりバックアップデータとオペレーションをテストし、予期せぬ事態に対して自分自身をテストすることは価値があることです。これは組織の準備態勢を検証し、まれで予期せぬ事態に対応する能力を付けるのに役立ちます。シミュレーションは現実的でなければならず、イベントに対応するために必要な組織横断的なチームを参加させる必要があります。

まず基本的で簡単なシミュレーションから始めて、次第に複雑なイベントを想定してください。例えば Amazon Virtual Private Cloud と関連リソースからなる現実的なモデルを構築し、不注意による情報の過剰露出や、ポリシーやアクセス制御リストの変更によるデータ漏洩の可能性についてシミュレートすることができます。インシデント対応計画がどの程度うまく機能したかを評価し、今後の対応手順に必要な改善点を特定するために得られた学びを文書化します。

AWS Backup を使用すると複数の AWS アカウントにまたがって、インスタンスレベルの自動バックアップとして Amazon Machine Image (AMI) を、ボリュームレベルの自動バックアップとしてスナップショットを設定することができます。これは、復旧ポイントを提供することにより、ランサムウェアのような潜在的なセキュリティイベントの範囲と影響を減らし、自動化されたフォレンジック対象ディスクの集約 のようなインシデント対応チームのフォレンジックプロセスを強化するのに役立つことができます。

まとめ

このブログ記事では AWS でバックアップデータを保護するためのセキュリティベストプラクティスと制御についてのトップ 10 を紹介しました。これらのベストプラクティスを利用して、ビジネスニーズを実現するために何重もの制御を備えたバックアップ & リカバリの戦略とアーキテクチャを設計し実装することをお勧めします。AWS Backup の詳細については AWS Backup のドキュメント を参照してください。

この記事に関するフィードバックがある場合は、以下のコメント欄でコメントを送信してください。この記事について質問がある場合は AWS Backup フォーラム で新しいスレッドを立ち上げる、もしくは AWS サポートへお問い合わせください。

さらに詳しい情報はこちら

その他の参考資料は以下になります。
Prescriptive Guidance : AWSにおけるバックアップ&リカバリのアプローチ
Blog : AWS Backupを使ったAWSサービス間での大規模な集中バックアップの自動化
Blog : AWS でのディザスタリカバリ (DR) アーキテクチャ、パートI:クラウドでのリカバリの戦略
Blog : 暗号化の重要性と AWS の支援方法
Blog : AWS Backup Vault Lock でバックアップのセキュリティ体制を強化する
Blog : AWS Backup Audit Manager を使用したバックアップコンプライアンスのモニタリング、評価、デモンストレーション
Blog : AWS Backup を使用してアカウントとリージョン間で暗号化されたバックアップを作成し共有する
Blog : AWS Backup Audit Manager でデータ保護ポリシーの監査をシンプルにする
Blog : AWS Backup でサービスコントロールポリシーを使用してバックアップへのアクセスを管理する
Blog : クロスアカウント・マルチリージョンから日次の AWS Backup 集計レポートを取得する

AWSセキュリティのニュースに興味を持たれた方は Twitter のフォローをお願いします。

著者について

Ibukun Oyewumi

AWS のセキュリティアシュアランスコンサルタント。セキュリティ管理、リスク管理、コンプライアンスのアーキテクト、構築、拡張、最適化の支援などに注力。

翻訳は Solutions Architect 片山洋平が担当しました。原文はこちらです。