# FISCREL1: 災害時におけるワークロードの復旧要件をどのように決定しますか？ ## ビジネスの重要度を使用して復旧目標を推進する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 74 ### ベストプラクティス - 回復力の要件を決定するための鍵は、ワークロードがサポートする機能の重要度を確立することです。金融機関は、回復力に関する規制要件を検討し、そうした要件を念頭に置いてアプリケーションを設計する必要があります。金融機関は、金融サービス機関が外部のエンドユーザーまたは参加者に提供するサービスを含む重要な機能を最大限に精査します。サービスの中断により、消費者または市場参加者に許容できない損害が発生し、市場の完全性が損なわれ、保険契約者の保護、安全性、健全性、または財政的安定が脅かされるからです。 - 重要なビジネスサービスに課せられる回復力の要件は、こうした重要性に比例する必要があります。これは、金融機関によって設定されるリスク選好に反映され、回復目標 (RTO、RPO) および可用性メトリクスを通知します。金融機関は、回復力がリスクを規定の範囲内に保つようにアプリケーションを設計し、可用性を監視して継続的に維持する必要があります。また、金融機関はコントロールと回復機能の信頼性をテストして、リスクが発生した場合に規定の範囲内でリスクを取り戻し、中断があっても継続的に運用できることを確認する必要があります。 ## 詳細なアプリケーションの復旧要件を適用する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 74 ### ベストプラクティス - アプリケーションの可用性を、初めにアプリケーション全体の単一ターゲットとして考えてしまうケースがよくあります。しかし詳しく分析してみれば、アプリケーションやサービスは、特定の側面によって求められる可用性がさまざまであることに気付くこともしばしばです。たとえば、システムによっては、既存データを取得するよりも、新しいデータを受信して保存する機能を優先させる場合があります。また、システムの構成や環境を変更するオペレーションよりも、リアルタイムオペレーションを優先させるシステムもあります。Well-Architected 信頼性の柱のホワイトペーパーでは、単一のアプリケーションを構成要素に分解し、それぞれの可用性要件を評価する方法のいくつかについて概説しています。分解のメリットは、システム全体を最も厳格な要件に合わせて設計するのではなく、特定のニーズに応じた可用性に労力をかけることができることです。 - コストは重要な要素であり、高レベルの可用性を設計することは非常にコストがかかる可能性があります。最も重要な部分を他の部分から分離することで、効果的なコストのトレードオフを行うことができ、重要な機能を提供しながらパフォーマンスの低下に対応できる機能を提供できます。 ## 復旧目標を満たすため、定義された復旧戦略を活用する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 74 ### ベストプラクティス - カテゴリごとに目標復旧時間 (RTO) と目標復旧時点 (RPO) を達成するための戦略を確立する: ワークロードにマルチリージョン戦略が必要な場合は、以下のいずれかの戦略を選択する必要があります。戦略は、複雑さの昇順、および RTO と RPO の降順でリストされています。別の AWS リージョンへのバックアップと復元により、必要なときにデータが利用可能になるという保証がさらに強化されますが、その他の戦略では、AWS リージョン内の複数のアベイラビリティーゾーンを使用して達成できる事柄と、潜在的な複雑さやコストを比較衡量する必要があります。 - バックアップと復元 (RPO (数時間以内)、RTO (24 時間以内)): データとアプリケーションを DR リージョンにバックアップします。障害からの復旧に必要な場合は、このデータを復元します。 - パイロットライト (RPO (数分以内)、RTO (数時間以内)): DR リージョンでシステムの最も重要なコア要素を常に実行している環境の最小バージョンを維持します。復旧の必要が生じたときに、重要なコアを中心として完全な本番環境をすばやくプロビジョンすることができます。 - ウォームスタンバイ (RPO (数秒以内)、RTO (数分以内)): 常に DR リージョンで実行されている完全に機能する環境の縮小バージョンを維持します。ビジネスクリティカルなシステムは完全に複製され、常に稼働していますが、フリートは縮小されています。復旧時には、システムをすばやくスケールアップして本番環境の負荷を処理できるようにします。 - マルチリージョンのアクティブ/アクティブ (RPO はなし、または数秒、RTO (数秒以内)): ワークロードは、複数の AWS リージョンにデプロイされ、複数の AWS リージョンからのトラフィックにアクティブに対応します。この戦略では、使用しているリージョン間でユーザーとデータを同期する必要があります。復旧時には、Amazon Route 53 や AWS Global Accelerator などのサービスを使用して、ワークロードが正常な場所にユーザートラフィックをルーティングします。 - AWS Resilience Hub でワークロードの RTO や RPO を含むレジリエンスポリシーを定義することで、構成されるインフラストラクチャやアプリケーション設定などを評価することができます。 ## DR サイトまたはリージョンでの設定ドリフトを管理する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 74 ### ベストプラクティス - デリバリーパイプラインがプライマリサイトとバックアップサイトの両方に配信しているようにします。: アプリケーションを本番環境にデプロイするための配信パイプラインは、開発環境やテスト環境など、指定されたすべての災害対策戦略のロケーションに分散する必要があります。 - AWS Config で潜在的なドリフトロケーションを追跡できるようにする: AWS Config ルールを使用して、災害対策戦略を適用し、ドリフトを検出したときにアラートを生成するシステムを作成します。 - AWS CloudFormation を使用してインフラストラクチャをデプロイする: AWS CloudFormation は、CloudFormation テンプレートが指定するものと実際にデプロイされているものとの間のドリフトを検出できます。また、CloudFront Stack Sets によりプライマリサイトとバックアップサイトのような複数のリージョンやアカウントに対して同じスタックを作成することができます。 ## 復旧を自動化する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 74 ### ベストプラクティス - 復旧経路の自動化: 復旧時間が短い場合に人が判断して対処する方法は、高い可用性シナリオには利用できません。システムはあらゆる状況下で自動的に復旧する必要があります。 - 自動フェイルオーバーとフェイルバックのために Elastic Disaster Recovery を使用する: Elastic Disaster Recovery では、プライマリサイトからバックアップサイトに継続的にレプリケートし、災害が発生した場合は、数千台のマシンを数分で完全にプロビジョニングされた状態で自動的に起動できます。 # FISCREL2: 本番システムの安全性を確保するためにソフトウェア開発ライフサイクル(SDLC) 環境 (開発、テスト、本稼働) 間の分離をどのように保証しますか? ## マルチアカウント戦略を持つ ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 76 ### ベストプラクティス - 別個の VPC にデプロイすることで環境を分離することができますが、別個の AWS アカウントにデプロイすると、最高レベルの分離を実現できます。AWS は、複雑さを処理するためのマルチアカウント戦略に関するパターンを提供します。お客様は、SDLC のステージに基づいて個別のアカウントを作成し、このマルチアカウント戦略を通じてセキュリティおよびインフラストラクチャポリシーを適用することを選択できます。この戦略は、設計による AWS の設計によるセキュリティ (Security by Design) の原則に基づいています。この原則は、AWS アカウントの設計を形式化し、セキュリティコントロールを自動化し、監査を効率化するセキュリティ保証アプローチです。 ## IAM の分離を実装する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 76 ### ベストプラクティス - さまざまな SDLC 環境専用にさまざまなアカウントを持つことで、IAM での特権の管理を自然に分離できます。AWS Organizations は、アカウント階層の管理を容易にします。サービスコントロールポリシー (SCP) を定義して、ユーザーがこれらのアカウント内で実行できるアクションを制限します。たとえば、本番環境で CloudTrail ロギングへの変更を防止したり、VPC でインターネットゲートウェイが設定されないようにしたり、AWS Config 追跡の変更を防止したりできます。 ## ネットワークの分離を実施する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 76 ### ベストプラクティス - IAM の分離に加えて、本番環境と非本番環境の間でリソースを明確に分離します。異なるアカウントを使用することで、AWS で可能な限り最高の分離形式を構築できます。ただし、特にロギングやセキュリティサービスなどの共有サービスにアクセスする場合は、アカウントを超えてリソースにアクセスできる必要がある場合があります。VPC ピアリングは、追加のゲートウェイや VPN 接続を必要とせずに、2 つの VPC (同じアカウントまたは異なるアカウント) にあるリソースを接続し、ピアリングされたすべてのネットワークを相互に認識できるようにします。これには、2 つの VPC 間で完全なネットワーク信頼が必要であり、ユースケースに応じてより適切な代替手段が存在します。 ## 予想されるネットワークトラフィックのベースラインを確立する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 76 ### ベストプラクティス - 高い、または予期しないネットワークトラフィックの状態を把握するには、ユーザーとシステム間の予想されるデータフローのメトリクスのベースラインを確立する必要があります。このベースラインは、ワークロードが DOS 攻撃を受けているか、予期しない負荷がかかっている場合に、運用上の応答をトリガーする必要があります。AWS は、DOS 攻撃に対する保護を提供できる多くのサービスを提供しています。AWS Shield および AWS Shield Advanced は、Amazon CloudFront、ELB、EC2 リソースで実行されているウェブアプリケーションに統合ウェブアプリケーションファイアウォール (AWS WAF) を提供します。VPC セキュリティグループやネットワークアクセスコントロールリスト (ACL) などの AWS 仮想ネットワーク機能も、ネットワーク攻撃に対する保護で効果的です。 # FISCREL3: コンポーネントの障害が発生した際にワークロードを保護またはリカバリするにはどうすればよいですか？ ## 複数の場所にワークロードをデプロイする ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 104 ### ベストプラクティス - ワークロードデータとリソースを複数のアベイラビリティーゾーンに分散するか、必要に応じて複数の AWS リージョンにかけて分散します。これらのロケーションは、必要に応じて多様化できます。 - 例えば、1 つの AZ が削除された場合にワークロードの負荷を処理するのに十分な数のインスタンスを各アベイラビリティーゾーンにプロビジョニングしてから、Elastic Load Balancing または Amazon Route 53 ヘルスチェックを使用して、障害のあるインスタンスから負荷を分散します。 - ワークロードのコンポーネントが 1 つのアベイラビリティーゾーンまたはオンプレミスのデータセンターでのみ実行できる場合は、定義された復旧目標内でワークロードを全面的に再構築する機能を実装する必要があります。 - リソース障害の発生時に、正常なリソースが引き続きリクエストに対応できるようにします。ロケーション障害 (アベイラビリティーゾーンや AWS リージョンなどにおける障害) に対しては、障害のないロケーションの正常なリソースにフェイルオーバーするシステムを用意します。 ## コードとしてのインフラストラクチャを実装する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 106 ### ベストプラクティス - コードとしてのクラウドとインフラストラクチャの利点は、プログラム的および自動的に環境全体を構築し、分離できるという能力です。回復力を念頭に置いて設計されている場合、AWS CloudFormation テンプレートまたは AWS Systems Manager 自動化を使用すれば、リカバリ環境を数分で実装できます。自動化は、高可用性と迅速な復旧を維持するために不可欠です。 - AWS は、回復力の目標を達成するための幅広い種類の自動化ツールを提供しています。AWS Systems Manager は、災害時のアプリケーションのリカバリ中に使用される完全なランブックを自動化するのに役立ちます。イベントの検出時に自動的に実行されるように、一連の操作を順位付けできます。Systems Manager 自動化ドキュメントを使用すると、これらのランブックをコードと同様に管理できます。それらをバージョン管理し、すべてのリリースと共に更新することができます。これにより、復旧計画をリリースされたコードおよびインフラストラクチャの更新と同期させることができます。 ## データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 106 ### ベストプラクティス - 復旧テストを実行して、バックアッププロセスの実装が目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たしていることを検証します。 - AWS を利用して、テスト環境を立ち上げ、そこにバックアップを復元して RTO および RPO が機能するかを評価し、データコンテンツと完全性のテストを実行できます。 - さらに、Amazon RDS および Amazon DynamoDB はポイントインタイムリカバリ (PITR) を許可します。継続的バックアップを使用すると、データセットを指定された日時の状態に復元できます。