# FISCOPS1: どのようにワークロードの変更を管理しますか？ ## オペレーションを記録する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 38 ### ベストプラクティス - オペレーションは自動化されたプロセスで行うことにより、手動プロセスにより発生するエラーと労力を減らすことができます。一方で、手動プロセスによるオペレーションが必要になる場合もあります。正当な権限を持つ自動化されたプロセスまたは運用者が正しくオペレーションを実施したことを保証するには、それらを記録、確認する機能が必要です。オペレーションには、AWS マネジメントコンソールからの操作だけでなく、コマンドラインからの操作、EC2 インスタンスにログインしての操作も含まれます。AWS CloudTrail は、インフラストラクチャの変更を記録、確認するのに有用です。また、AWS Systems Manager Session Manager を使って、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、エッジデバイス、オンプレミスサーバー、仮想マシン (VM) を管理できます。 Session Manager は、マネージドノードの制御されたアクセス、厳格なセキュリティプラクティス、ノードアクセス詳細がある完全監査可能なログを要件とする社内ポリシーの尊守を実現しつつ、エンドユーザーが簡単なワンクリック・クロス プラットフォームアクセスによってマネージドノードの使用を実現します。 ## コードとしてインフラストラクチャを実装する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 42 ### ベストプラクティス - コードとしてのクラウドとインフラストラクチャの利点は、プログラム的および自動的に環境全体を構築し、分離できるという能力です。回復力を念頭に置いて設計されている場合、AWS CloudFormation テンプレートまたは AWS Systems Manager 自動化を使用すれば、リカバリ環境を数分で実装できます。AWS Config の設定スナップショットは、アカウント内のサポートされているリソースに関する設定項目のコレクションです。設定スナップショットは、記録対象のリソースとその設定の全体像を示します。設定スナップショットは設定を検証するのに役立ちます。 ## アプリケーションの改ざんを防ぐ ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 40、実 96 ### ベストプラクティス - アプリケーションの改ざん、破壊、消去を防ぐため、コードとアーティファクトのバージョン管理を行う必要があります。また、開発中のコード、アーティファクトが誤って本番環境に混入しないよう、本番環境のコード、アーティファクトと開発中のコード、アーティファクトは分離して管理する必要があります。AWS CodeCommit は、プライベート Git リポジトリをホストする、安全で高度にスケーラブルなマネージド型のソース管理サービスです。AWS IAM による条件付きポリシーを作成することで、一部のリポジトリユーザーだけが本番ブランチにコードをプッシュまたはマージできるように、ブランチを設定することもできます。また、Amazon S3 オブジェクトロックでは、Write Once Read Many (WORM) モデルを使用してオブジェクトを保存できます。オブジェクトロックにより、オブジェクトが削除または上書きされることを、一定期間または無期限に防止できます。AWS Lambda でコード署名を使用すると、信頼できるコードのみを Lambda 関数で実行するようにできます。関数のコード署名を有効にすると、デプロイされたすべてのコードが Lambda によりチェックされ、コードパッケージが信頼できるソースによって署名されていることを確認できます。 ## 開発時から品質向上に取り組む ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 96 ### ベストプラクティス - 開発時からコードの品質向上に取り組むことが、最終的なアプリケーションの品質向上に役立ちます。一方で、開発者がコードの問題を特定するには時間と労力がかかります。支援ツールを活用してコードレビューを自動化することで、開発者の労力を減らしつつ、新たなバグの発生や、脆弱性の組み込みのリスクを緩和することができます。Amazon CodeGuru Reviewer は機械学習および自動推論を使用して、アプリケーション開発中に重大な問題、セキュリティの脆弱性、見つけにくいバグを特定し、推奨事項を提供することで、コードの品質を向上します。 # FISCOPS2: どのようにワークロードの障害を迅速に検知しますか？ 重要な機能をサポートするワークロードが高可用性を保つには、障害を検出してそれらから迅速に復旧する機能が必要です。運用モデルに組み込むことができるクラウド内のメトリクスを定義、収集、分析することで、ワークロードの運用状態を把握できます。これらのメトリクスは、コード、ワークロード、ユーザーアクティビティによって生成され、実際のパフォーマンスデータを視覚化および調査するために使用できる一元化された照会可能なシステムに収集する必要があります。これは、アプリケーションログ、Amazon CloudWatch、システムログ、AWS CloudTrail ログなど、各種ログを単独で見るだけでは明確にならないことが多い問題を診断するために重要です。 ## クラウドプロバイダーのイベントを監視する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 46 ### ベストプラクティス - 金融機関は、AWS でワークロードに影響を与える可能性のあるイベントが発生したときにアラートと修復のガイダンスを提供する AWS Health Dashboard を使用する必要があります。ダッシュボードには、関連する情報が適切なタイミングで表示されるため、進行中のイベントを管理するのに役立ちます。また、積極的な通知は、スケジュールされたアクティビティを計画するのに役立ちます。AWS Health Dashboard では、ご使用中のアプリケーションで使用されている AWS リソースの状態に変化があった場合にアラートがトリガーされます。イベントが可視化され問題をすばやく診断して解決するためのガイダンスが表示されます。AWS Health API にアクセスできるエンタープライズサポートおよびビジネスサポートのお客様は、この API を使用して、AWS Health Dashboard から情報を一元化された監視システムに統合し、一貫性のある包括的なアラートメカニズムを定義することができます。 ## 監視で一括管理を行う ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 46 ### ベストプラクティス - AWS クラウドサービスは堅牢なモニタリングを提供しますが、データを整理して、問題をできるだけ早くエスカレーションする必要があります。適切なプロセスが配置されていないと、問題の先行指標を見逃す可能性があります。組織全体で一括管理とクラウド監視標準を標準化することで、情報サイロを回避し、監視データの分析を簡素化できます。AWS、システムメトリクス、アプリケーションログのモニタリングを組み合わせることで、アナリストはシグナルを相互参照し、依存するシステム間で情報をログに記録できます。多くの場合、問題は呼び出しシステムで表面化し、IT プロフェッショナルは、エラーが発生した対象システムではなく、呼び出しシステムでログの解析に時間を費やします。 ## 負荷テストを通じてメトリクスを特定し、アラートを検証する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 46 ### ベストプラクティス - スケーリングと回復力を検証するには、定期的にワークロードの負荷テストを実行する必要があります。こうした負荷テスト中のキャパシティの制約と顧客による停止に相関する主要なメトリクス (需要に合わせて自動スケーリングするコンポーネントと、リレーショナルデータベースなど自動スケーリングしないリソースの両方) を特定します。監視するアラートとダッシュボードを作成します。 アプリケーションテストの一部として、自動アラートの検証と修正を含めます。負荷が低い環境で負荷テストを実行し、アラートのトリガーを特定して、自動修復の有効性を確認します。ワークロードの平均検出時間 (MTTD) を最小限に抑えることができれば、回復メカニズムが応答する時間が長くなり、アプリケーションの可用性が向上します。 # FISCOPS3: ワークロードのバックアップをどのように取得しますか？ ## データバックアップと保持の要件を理解する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 39 ### ベストプラクティス - ワークロードの回復力の要件を決定する重要なタスクは、データのバックアップと保持のニーズを特定することです。金融機関では、システム内のデータのバックアップと保持に関する標準があり、規制要件によって通知される場合があります。金融サービス業界のお客様は、ご使用の環境で実行されているワークロードに適用される要件を理解する必要があります。 ## ランサムウェア対策のバックアップをバックアップ戦略に組み込む ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 39 ### ベストプラクティス - 通常のバックアップサイクルに加えて、短期間のランサムウェア対策バックアップをバックアップサイクルに組み込む必要があります。ランサムウェアはすぐに認識されるため、こうした追加のバックアップは 1〜2 日だけ保持します。これにより、追加のストレージコストが制限されます。ランサムウェア攻撃から保護するためのバックアップサイクルと保存期間を定義します。データのリージョンでのコピーで十分ですが、これらのバックアップへのアクセスは厳しく制限する必要があります (バックアップもソースと同様に暗号化する必要があります)。 ## バックアップのライフサイクルポリシーを作成する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 39 ### ベストプラクティス - 規制要件に基づいて、AWS でデータを保持およびパージするライフサイクルポリシーを作成します。Amazon S3 のデータに関しては、S3 ライフサイクルポリシーにより、最も適切なストレージ階層へのデータの移行を自動化できます。AWS Backup は、タグベースのポリシーを通じて、環境全体でデータの保持を管理できます。 ## データファイルの継続的なバックアップを確保する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 39 ### ベストプラクティス - ワークロードのデータに対しては、バックアップ戦略を定期的または継続的に実行する必要があります。バックアップを実行する頻度によって、達成できる復旧時点が決まります (RPO を満たすように調整する必要があります)。バックアップは、バックアップを作成した時点に復元する方法も提供する必要があります。ポイントインタイムリカバリによるバックアップは、以下のサービスとリソースを通じて利用できます。 - [Amazon Elastic Block Store (Amazon EBS) スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) - [Amazon DynamoDB バックアップ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html) - [Amazon RDS スナップショット](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html) - [Amazon Aurora DB スナップショット](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_CreateSnapshotCluster.html) - [Amazon EFS バックアップ](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) (AWS Backup の使用時) - [Amazon Redshift スナップショット](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html) - [Amazon Neptune スナップショット](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-overview.html) - Amazon Simple Storage Service (Amazon S3) では、[Amazon S3 クロスリージョンレプリケーション (CRR)](http://aws.amazon.com/s3/features/replication/) を使用して、オブジェクトを継続的に DR 用リージョンの S3 バケットに非同期的にコピーするとともに、保存したオブジェクトのバージョニングを提供して復元ポイントを選択できます。データの継続的レプリケーションには、データのバックアップ時間が最短 (ゼロに近い) という利点がありますが、データの破損や悪意のある攻撃 (不正なデータ削除など) などの災害イベントから保護できない場合があります。ポイントインタイムバックアップもできません。継続的レプリケーションについては、「[パイロットライト向けの AWS のサービス](https://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#aws-services-1)」セクションで説明しています。 - AWS Backup は、以下のサービスとリソースに対して AWS のバックアップ機能を設定、スケジュール、モニタリングするための一元化された場所を提供します。 - [Amazon Elastic Block Store (Amazon EBS)](http://aws.amazon.com/ebs/) ボリューム - [Amazon EC2](http://aws.amazon.com/ec2/) インスタンス - [Amazon Relational Database Service (Amazon RDS)](http://aws.amazon.com/rds/) データベース ([Amazon Aurora](http://aws.amazon.com/rds/aurora/) データベースを含む) - [Amazon DynamoDB](http://aws.amazon.com/dynamodb/) テーブル - [Amazon Elastic File System (Amazon EFS)](http://aws.amazon.com/efs/) ファイルシステム - [AWS Storage Gateway](http://aws.amazon.com/storagegateway/) ボリューム - [Amazon FSx for Windows ファイルサーバー](http://aws.amazon.com/fsx/windows/) および [Amazon FSx for Lustre](http://aws.amazon.com/fsx/lustre/)、[Amazon FSx for NetApp ONTAP](https://aws.amazon.com/jp/fsx/netapp-ontap/)、[Amazon FSx for OpenZFS](https://aws.amazon.com/jp/fsx/openzfs/) AWS Backup は、リージョン間でのバックアップのコピー (災害対策リージョンへのコピーなど) をサポートしています。 Amazon S3 データの追加の災害対策戦略として、[S3 オブジェクトのバージョニング](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html)を有効にします。オブジェクトのバージョニングは、削除や変更のアクションの前に元のバージョンを保持することで、アクションの結果から S3 内のデータを保護します。オブジェクトのバージョニングは、人為的なミスに伴う災害への有効な軽減策となります。S3 レプリケーションを使用してデータを DR 用リージョンにバックアップしている場合、デフォルトでは、レプリケート元バケットでオブジェクトが削除されると、[Amazon S3 はレプリケート元バケットにのみ削除マーカーを追加](https://docs.aws.amazon.com/AmazonS3/latest/dev/delete-marker-replication.html)します。このアプローチは、DR 用リージョンのデータをレプリケート元リージョンでの悪意のある削除から保護します。 ## インフラストラクチャ構成情報のバックアップを確保する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 43 ### ベストプラクティス - データに加えて、ワークロードの再デプロイと目標復旧時間 (RTO) の達成に必要な設定とインフラストラクチャもバックアップする必要があります。AWS CloudFormation では、Infrastructure as Code (IaC) を提供し、ユーザーがワークロード内のすべての AWS リソースを定義して、複数の AWS アカウントや AWS リージョンに確実にデプロイおよび再デプロイできるようにします。これにより、Amazon VPC、AWS Transit Gateway、セキュリティグループなどの各種ネットワーク構成を含めたインフラストラクチャ構成が再デプロイ可能になります。 また、ワークロードで使用する Amazon EC2 インスタンスを Amazon マシンイメージ (AMI) としてバックアップできます。AMI は、インスタンスのルートボリュームと、インスタンスにアタッチされたその他の EBS ボリュームのスナップショットから作成します。この AMI を使用して、復元したバージョンの EC2 インスタンスを起動できます。[AMI のコピー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html)はリージョン内またはリージョン間で行うことができます。または、AWS Backup を使用して、バックアップをアカウント間でコピーしたり、他の AWS リージョンにコピーしたりできます。クロスアカウントバックアップ機能は、内部関係者による脅威やアカウントの侵害などの災害イベントからの保護に役立ちます。AWS Backup は、EC2 バックアップに他の機能も追加します。インスタンスの個々の EBS ボリュームに加えて、AWS Backup は、インスタンスタイプ、設定済みの仮想プライベートクラウド (VPC)、セキュリティグループ、IAM ロール、モニタリング設定、タグなどのメタデータも保存および追跡します。ただし、この追加メタデータは、EC2 バックアップを同じ AWS リージョンに復元する場合にのみ使用します。 # FISCOPS4: 重要なドキュメントをどのように管理しますか？ ## バージョン管理を行う ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 44 ### ベストプラクティス - 設計資料や手順書などのワークロードの運用において重要なドキュメントをバージョン管理します。ドキュメントの更新時には、ドキュメントに責任を持つ者の承認を必要とすることで、意図しない変更や改ざんを防止します。 AWS CodeCommit は、クラウド内のアセット(ドキュメント、ソースコード、バイナリファイルなど) を非公開で保存および管理するために使用できるアマゾン ウェブ サービスによってホストされるバージョン管理サービスです。AWS CodeCommit を利用して、プルリクエストを作成することが可能です。プルリクエストは、お客様と他のリポジトリーユーザーが、ブランチから別のブランチへのコード変更を確認、コメント、およびマージすることができる主な方法です。プルリクエストを使用すると、わずかな変更や修正、主要な機能の追加、リリースされたソフトウェアの新しいバージョンのコード変更を共同で確認することができます。 ## 閲覧を適切な範囲に制限する ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 44 ### ベストプラクティス - 重要なドキュメントの悪用を防ぐため、適切な個人またはチームのみがドキュメントが閲覧可能になるよう制限を行います。 AWS CodeCommit は AWS IAM を使用してアクセスを管理することができます。 ## 災害対策に必要なドキュメントのバックアップを行う ### 対応する FISC 安全対策基準・解説書の実務基準番号 実 45 ### ベストプラクティス - 災害発生時の復旧を確実に行うため、必要なドキュメントのバックアップを行います。AWS CodeCommit リポジトリのリージョン間レプリケーションについては[こちらの記事](https://aws.amazon.com/jp/blogs/news/replicate-aws-codecommit-repository-between-regions-using-aws-fargate/)を参照してください。