# FISCSEC1: アクセス許可をどのように設定・管理していますか？

不正アクセス等から重要なデータを保護するため、必要最低限のアクセス許可設定が必要になります。また、アクセス権限については人事異動などに伴い速やかに変更されることが求められており、アクセス権限の見直し手続きを明確にする必要があります。

## 不正アクセス等から重要なファイルを保護するため、重要なファイルについてはアクセス制御を適切に設定します。

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 5

### ベストプラクティス

- AWS リソースへのアクセス権限について、付与されている権限のうち、利用されていない権限について AWS Identity and Access Management (IAM) アクセスアドバイザーで最終アクセス時間を確認することで検出することが可能になります。アクセス権限の妥当性について確認を行い、不要であれば削除します。
- インバウンドトラフィックとアウトバウンドトラフィックの両方について、多層防御アプローチでコントロールを適用します。たとえば、Amazon Virtual Private Cloud (VPC) の場合、これにはセキュリティグループ、ネットワーク ACL、サブネットが含まれます。
- 重要なファイルへのアクセスについて、VPC からのみアクセスを許可することで、ネットワークレイヤでの対策を追加することが可能になります。例えば Amazon S3 に保存する場合、VPC エンドポイントやパブリックブロックアクセスを活用することで実現することが可能です。

## 渉外端末等、決まった拠点以外での操作が可能になる端末かどうかを識別し、権限の範囲を明確にする必要があります。

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 61

### ベストプラクティス

- AWS リソースへのアクセス権限について、外部エンティティと共有されている Amazon S3 バケットや IAM ロールなど、重要なリソースについて意図しないアクセスが許可されていないか、AWS IAM Access Analyzer を確認することで検出することが可能になります。アクセス権限の妥当性について確認を行い、不要であれば削除します。

## 個人データ等を扱うシステムについては、アクセス権限の付与、削除等のオペレーションが明確である必要があります。

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 27

### ベストプラクティス

- AWS リソースへのアクセス権限付与について、アクセス権限の申請者と承認者で相互牽制が働く構造とすることが推奨されます。IAM エンティティのアクセス許可境界 を利用することで、アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限を設定することが可能です。エンティティのアクセス許可の境界により、エンティティは、アイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できます。また、特権の昇格を防ぐために、サービスコントロールポリシー (SCP) を利用してアカウント内のユーザー (IAM 管理者または委任された管理者を除く) が管理 IAM アクションを使用できないよう制御することも可能です。
- アクセス権限は一定期間での見直しが求められますが、それ以外にも、所属や組織の変更に伴う人事異動時、入社や退職、休職、長期の出張、システムの追加やリタイア等のタイミングでも見直しを行うことが必要となります。アクセス権限の見直しは、人に属する権限に限定せず、サーバーリソースに付与されている権限についても見直しが必要です。アクセス権限の管理・変更は、クラウド利用者側でのワークフロー対応の他、AWS Identity and Access Management (IAM) アクセスアドバイザーによる不要なアクセス権限付与の確認や、AWS IAM Access Analyzer による意図しないアクセス許可の確認が有効です。

# FISCSEC2: システムの操作記録検証のためにどのような情報を収集していますか？

## AWS アカウントのアクティビティを監視します。

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 63

### ベストプラクティス

- 各アカウントで AWS CloudTrail をオンにして、サポートされている各リージョンで使用します。
- アクセスが非常に制限されている一元化されたログアカウントに AWS CloudTrail ログを保存します。CloudTrail ログファイルの整合性の検証を使用することでログファイル自体が変更されていないこと、または特定のユーザーの認証情報が特定の API アクティビティを実行したことを確実に検証することができます。CloudTrail ログファイルの整合性の検証プロセスでは、ログファイルが削除または変更されたかどうかを知ることもできます。また、指定された期間内にログファイルがアカウントに配信されていないことを確実に検証することが可能です。
- CloudTrail ログファイルを定期的に調べます。また、AWS CloudTrail イベント、VPC フローログ、DNS ログを継続的に分析することで脅威を検出するサービスである GuardDuty を使用することもできます。
- Amazon S3 バケットのロギングを有効にして、各バケットに対して行われたリクエストを監視します。
- アカウントが不正に使用されたと考えられる場合は、発行された一時的な認証情報に注意してください。認識できない一時的な認証情報が発行された場合は、それらのアクセス許可を無効にします。
- サービスの最終アクセス時間データを使用して、IAM ロールを定期的に確認します。IAM エンティティ (ユーザーまたはロール) が最後にサービスにアクセスを試みたときのレポートを表示できます。次に、その情報を使用してポリシーを調整し、使用中のサービスのみへのアクセスを許可することができます。IAM のリソースの種類ごとにレポートを生成できます。詳細については、サービスの最終アクセス時間データの表示プロセスのドキュメントをお読みください。

## AWS アカウントのアクティビティと実際の利用者の関連付けについて、検証を可能にします。管理者、開発者、オペレーター、エンドユーザーは、AWS 環境とアプリケーションにアクセスするために ID を必要とします。これらの者は、あなたの組織のメンバー、または共同作業を行う外部ユーザーで、ウェブブラウザ、クライアントアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースを操作する人たちです。AWS リソースの操作を実行したユーザーと実際の利用者について関連付けを可能にし、誰がその操作を実行したのかを検証可能にしておくことが求められます。

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 63

### ベストプラクティス

- 一元化された場所で ID を管理できる ID プロバイダーを利用します。これにより、1 つの場所からアクセスを作成、管理、取り消すことができるため、アクセスの管理が容易になります。これにより、複数の認証情報の要件が軽減され、HR プロセスと統合する機会がもたらされます。HR プロセスとの統合は、操作を実行したユーザー ID と実際の操作者本人との関連付けを容易にし、操作実行者の検証を効果的に行うことが可能となります。
- ユーザーグループと属性を活用します。一般的なセキュリティ要件を持つユーザーを ID プロバイダーによって定義されたグループに配置し、アクセスコントロールに使用される可能性のあるユーザー属性 (部署や場所など) が正確で、最新の状態に保たれるようにするメカニズムを導入します。アクセスを制御するには、個々のユーザーではなくこれらのグループと属性を使用します。これにより、ユーザーのアクセスニーズが変化したときに多くの個別のポリシーを更新することなく、ユーザーのグループメンバーシップや属性を 1 回変更することで、アクセスを一元管理できます。

# FISCSEC3: システムへ入力されるデータに対し、不良データの混入や不正からの保護のため、どのような対策を取っていますか？

## アプリケーションレイヤでの入力チェックの他、データに対する処理履歴を収集・管理することにより不良データの混入や不正からデータを保護することが可能です。

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 6, 実 65

### ベストプラクティス

- AWS Config を使用します。AWS Config を有効にして、リソース構成の変更を追跡し、リソース構成に関する質問に回答し、特定の時点または一定期間にわたってコンプライアンスを実証し、トラブルシューティングを行い、セキュリティ分析を実行します。構成変更通知を処理するときは、ワーカーで AWS Lambda または Amazon Simple Queue Service (SQS) を活用して、変更通知やアラートを処理、フィルタリング、統合します。
- Amazon S3 バージョニングを使用します。S3 Versioning を使用すると、オブジェクトの複数のバージョンを 1 つのバケットに保持し、誤って削除または上書きされたオブジェクトを復元できます。例えば、オブジェクトを削除した場合、Amazon S3 はオブジェクトを完全に削除する代わりに削除マーカーを挿入します。これが最新のオブジェクトバージョンになります。これにより、以前のバージョンを復元できます。オブジェクトを上書きすると、バケット内の新しいオブジェクトバージョンになります。いつでも以前のバージョンを復元できます。
- Amazon S3 アクセスログを使用します。サーバーアクセスのログには、バケットに対するリクエストの詳細が記録されます。Amazon S3 アクセスログにより、データの新規作成処理について情報の収集・管理を実現することが可能になります。
- AWS CloudTrail を使用します。AWS のサービスによって実行されたアクションは、CloudTrail にイベントとして記録されます。AWS のサービスに対する処理履歴の収集・管理を実現することが可能になります。

# FISCSEC4: 顧客データを保護し、適正に利用するため、どのようにデータを分類・管理していますか?

## 金融サービス機関は、データ分類を使用して、機密データまたは重要なデータを適切なレベルの保護で保護する判断を下します。データがオンプレミスシステムまたはクラウドのどちらで処理や保存されているかに関係なく、データ分類は、組織に対するリスクに基づいて、データの機密性、整合性、可用性に対する適切なコントロールレベルを決定するための開始点です。データを分類し、クラウド環境内で適切なコントロール (暗号化など) を実装するのはお客様の責任です。AWS がインフラストラクチャや提供するサービス内に実装するセキュリティコントロールは、最も機密性の高いデータ要件を満たすために使用できます。

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 69

### ベストプラクティス

- データ分類に基づいて AWS のサービスにタグを付けます。データ分類フレームワークに基づいて AWS リソースでタグを使用して、データガバナンスプログラムへのコンプライアンスを実装します。このコンテキストでのタグ付けは、データの暗号化、保持、アーカイブの有効化と検証などの自動化に使用できます。
- 分類に基づいてアクセスを制限します。リソースタグと IAM ポリシーを AWS KMS や CloudHSM とともに使用して、データ分類に基づいて保護を実施する独自のポリシーを定義および実装します。たとえば、非常に重要で機密性の高いデータを含むまたは処理する S3 バケットまたは EC2 インスタンスがある場合は、 それらに DataClassification=CRITICAL タグを付けて、 そこに存在するデータを自動的に、AWS KMS で暗号化します。適切なサービスのみが機密コンテンツにアクセスできるようにするには、キーポリシーを使用してそれらの KMS 暗号化キーへのアクセスレベルを定義します。
- 暗号化における鍵管理の権限分離を実装します。データの暗号化を行う際は、暗号化を行う秘密鍵の管理者とデータを所有するリソースの管理者を分離することでより強固なセキュリティ対策を採用することが可能です。AWS Key Management Service (AWS KMS)でカスタマーマネージドキーを使用することで、キーポリシーによりアクセス許可を定義することが可能になります。 例えば、故意／過失に依らず Amazon S3 内のオブジェクトを不特定多数のインターネットに公開してしまった場合でも、暗号化を行う秘密鍵のキーポリシーでインターネットから秘密鍵へのアクセスが許可されていなければ、インターネットから Amazon S3 内のオブジェクトにはアクセスできません。

# FISCSEC5: どのようにアイデンティティを保護し、システムの不正使用を防ぎますか？

## ユーザーのために強度の高いパスワードポリシーを設定する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 1、実 26

### ベストプラクティス

ユーザーが各自のパスワードを変更できるように許可する場合は、強力なパスワードを作成することをユーザーに要求するパスワードポリシーを作成します。
IAM ユーザーのデフォルトのパスワードポリシーでは、次の条件が適用されます。

- パスワードの文字数制限: 8 ～ 128 文字
- 大文字、小文字、数字、! @ # $ % ^ & \* ( ) \_ + - = [ ] { } | ' 記号のうち、最低 3 つの文字タイプの組み合わせ
- AWS アカウント名または E メールアドレスと同じでないこと

必要に応じて、IAM コンソールの [Account Settings (https://console.aws.amazon.com/iam/home?#account_settings)] (アカウント設定) ページで、AWS アカウントのカスタムパスワードポリシーを作成できます。AWS のデフォルトのパスワードポリシーからアップグレードして、最小文字数、アルファベット以外の文字が必要かどうか、変更頻度など、パスワードの要件を定義します。詳細については、「IAM ユーザー用のアカウントパスワードポリシーの設定 (https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)」を参照してください。

## 初回サインイン時のパスワード変更を強制する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 1、実 26

### ベストプラクティス

ID の使用者のみがパスワードを知っている状態を担保するため、ID を発行後、初回サインイン時にパスワードの変更を強制します。IAM ユーザーに初回サインイン時に新しいパスワードの作成を求めるには、AWS マネジメントコンソールの IAM ユーザー作成ウィザードで、[Require password reset (パスワードのリセットが必要)] を選択します。
安全な IAM ユーザーの作成方法は[こちら](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_securely-create-iam-users)を参照してください。

## システムへの接続元を必要最小限に制限する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 8

### ベストプラクティス

システムへの接続許可を、正当な端末やネットワークを利用して接続する場合のみに与えるよう構成することで、不特定多数の端末からの不正アクセスを防止します。接続元の確認方法としては、認証情報、IP アドレス、クライアント証明書などがあり、これらを組み合わせて利用することでセキュリティを強化できます。  
AWS マネジメントコンソールへの API 呼び出しを特定の IP アドレス範囲に限定するには、 一連のアクセス許可がアタッチされた IAM ロール を作成し、aws:SourceIp 条件キーを使用して IAM ロールを引き受けるアクセス許可を IAM ユーザーに付与します。詳細については[こちら](https://aws.amazon.com/jp/premiumsupport/knowledge-center/iam-restrict-calls-ip-addresses/)を参照してください。
AWS 外のワークロードやアプリケーションなどから AWS の API 呼び出しが必要な場合は、クライアント証明書を利用した一時認証情報の取得を検討します。詳細は [IAM Roles Anywhere](https://docs.aws.amazon.com/ja_jp/rolesanywhere/latest/userguide/introduction.html)を参照してください。

## アイデンティティと接続を一元管理する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 26

### ベストプラクティス

複数のシステムやアプリケーションへの接続が必要な場合は ID の一元管理を検討します。これによりユーザーはアプリケーションごとに個別のパスワードを使用する必要がなくなり、強度の低いパスワードの設定やパスワードの使い回しなど、パスワードの漏洩につながるリスクを軽減できます。  
AWS Organizations と統合して AWS IAM Identity Center（旧 AWS SSO) を使用することで、複数の AWS アカウントへのアクセスの管理が可能となります。個々のアカウントにおける追加のセットアップは不要です。ユーザー ID は、AWS IAM Identity Center で直接作成することもできますし、Microsoft アクティブディレクトリや、Okta Universal Directory や Azure AD などの標準ベースの ID プロバイダーから持ってくることもできます。AWS IAM Identity Center は AWS アカウントへのアクセスだけでなく、AWS IAM Identity Center 統合アプリケーション、事前統合された SAML アプリケーション、SAML 2.0 を使用したカスタムアプリケーションへの接続をサポートします。

# FISCSEC6: どのようにサービスの不正利用の対策を行いますか？

## 顧客への通知を行う

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 112

### ベストプラクティス

- 決済などの特定取引を行う際には、接続相手先が本人であることを確認する予防策として、SMS など登録情報を利用した追加認証を実施します。また、取引の完了時には、顧客への通知を実装します。Amazon Simple Notification Service (SNS) を用いることで、顧客へ SMS を送信します。不正利用の発見/防止に利用することが可能です。

# FISCSEC7: どのようにセキュリティインシデントの対策を行いますか？

## アクセス履歴と状況を管理する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 11、実 16、実 113

### ベストプラクティス

- ブルートフォース攻撃や不正アクセスを検知するために、ログイン試行回数やログイン履歴などのアプリケーションログを収集します。CloudWatch エージェントや Kinesis エージェントを EC2 にインストールすることで、AWS 上で業務アプリケーションのログを収集することができます。コンテナを実行する場合には、Firelens を用いてログを AWS 上に保存することができます。データベースへのアクセス状況を把握するためには、監査ログが利用できます。
- 多要素認証 (MFA) の有無やアクセス元 IP アドレスに応じて、アクセス権を制限します。例えば、本番環境などのリソースにアクセスできる IAM ロールの割り当てには、特定 IP アドレスからのアクセスおよび MFA 利用の要求を設定します。

## ネットワークリソースを保護する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 16

### ベストプラクティス

- 予期されるネットワークトラフィックと予期しないネットワークトラフィックを監視します。不規則なアクセスやネットワークトラフィックを特定します。例えば、ネットワークのメトリクスを監視し、通常時よりも多大なトラフィックが検知される場合は攻撃を受けている可能性があります。予期しない外部システムへの接続の試みは、内部ホストが侵害されている可能性があります。
- VPC フローログで IP トラフィックに関する情報を記録します。GuardDuty を用いて悪意のある動作や不正な動作を継続的にモニタリングし、AWS のアカウントとワークロードを保護します。
- AWS Web Application Firewall (WAF) や AWS Shield を用いて外部に公開している Web サイトをサービス妨害攻撃から守ります。AWS WAF では、定義された条件に基づきウェブリクエストを許可、ブロック、監視するルールを設定し、ワークロードを保護します。例えば、レートベースのルールを設定することで、5 分間に一定数以上のリクエストを行った IP アドレスをブロックします。AWS Shield Standard は自動的に有効化され、SYN/UDP フラッド攻撃やリフレクション攻撃といったレイヤー 3 とレイヤー 4 に対する攻撃からワークロードを守ります。AWS Shield Advances を追加で有効化することで、レイヤー 7 に対する DDoS 攻撃を自動的に緩和します。

## アプリケーションの動作を監視する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 18

### ベストプラクティス

- 不正利用を検知するために、「アクセス履歴と状況を管理する」の方法で収集したログを分析します。CloudWatch Logs インサイトを用いた分析結果や CloudWatch Logs メトリクスフィルタによって監視されるメトリクスを用いて、CloudWatch Alarm や AWS Lambda のトリガーを行います。ニアリアルタイムの検知を行う場合には、Amazon Kinesis Data Analytics、AWS Lambda、Amazon OpenSearch Service を用いてログを分析します。
- 収集したログの改ざんや削除を防止するため、アクセスを制限します。例えば、ログファイルへのアクセス権限を専用端末にのみ付与し、通常の端末からのアクセスを明示的に拒否します。マルチアカウント戦略を用いる場合には、ログを専用のアカウントに集約します。ログへのアクセスが可能なアカウントを制限します。また、S3 のオブジェクトロック機能を利用することで、専用のアカウントからもログの改ざんや削除ができないように設定します。

# FISCSEC8: 暗号化キーをどのように管理していますか？

## 暗号化キーを安全に管理する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 13、実 30

### ベストプラクティス

- AWS Key Management Service (AWS KMS) は、カスタマーマスターキー (CMK) によるエンベロープ暗号化戦略を採用しています。エンベロープ暗号化は、平文データをデータキーで暗号化し、次にデータキーを別のキー、即ち CMK で暗号化する方法です。AWS KMS の外部でデータの暗号化に利用するデータキーは、CMK により生成、暗号化、復号されています。CMK は AWS KMS で作成され、暗号化されていない状態のままになることはありません。
- AWS KMS は、カスタマー管理の CMK、AWS 管理の CMK、AWS 所有の CMK という 3 種類の CMK をサポートします (詳細については、 https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys を参照してください)。多くの金融機関のお客様にとって、カスタマー管理の CMK は、お客様のアプリケーションと AWS のサービスの両方からのアクセス権限を管理できるため推奨されます。カスタマー管理の CMK は、キーの生成や保管にさらなる柔軟性も提供します。また、キーの使用またはポリシーの変更はすべて、監査目的で AWS CloudTrail を用いて記録します。

## 暗号化キーのローテーションを行う

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 30

### ベストプラクティス

- 同じ暗号化キーの長期間利用を避け、CMK の自動キーローテーションを有効にします。カスタマー管理の CMK の自動キーローテーションを有効にすると、AWS KMS は CMK の新しいキーマテリアルを毎年生成します。AWS KMS は既存のデータキーで暗号化したデータも復号できるように、既存のキーマテリアルも保存します。
- 自動キーローテーションは、既存のデータキーで暗号化されているデータには影響しません。既存のデータキーを変更することや、既存のデータキーで暗号化されているデータを再び暗号化することはありません。また、既存のデータキーが侵害された場合、自動キーローテーションではその影響を軽減することはできません。新しいデータキーを用いて再び暗号化する必要があります。

## 暗号化における鍵管理の権限を分離する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 30

### ベストプラクティス

- データの暗号化を行う際は、暗号化を行う秘密鍵の管理者とデータを所有するリソースの管理者を分離することでより強固なセキュリティ対策を採用することが可能です。AWS KMS でカスタマーマネージドキーを使用することで、キーポリシーによりアクセス許可を定義することが可能になります。例えば、故意/過失に依らず Amazon S3 内のオブジェクトを不特定多数のインターネットに公開してしまった場合でも、暗号化を行う秘密鍵のキーポリシーでインターネットから秘密鍵へのアクセスが許可されていなければ、インターネットから Amazon S3 内のオブジェクトにはアクセスできません。

# FISCSEC9: マルウェアからどのようにシステムを守りますか？

## コンピューティングリソースを保護して、マルウェアの侵入を防ぐ

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 22、実 32

### ベストプラクティス

- コンピューティングリソースを保護して、マルウェアのインストールに悪用される可能性のある脆弱性に対してパッチが適用されていることを確認します。コンピューティングリソースに自動的にパッチを適用し、コンプライアンスを監視できるようにします。
- 利用者が定めた基準に準拠しているゴールデンイメージを作成し配布します。基準に準拠しているゴールデンイメージのみ使用を許可します。EC2 Image Builder を使用して、Amazon EC2 で使用する Linux または Windows Server のイメージを作成、保守、検証、共有、デプロイします。 また、ウイルス対策およびエンドポイント保護エージェント、ファイルの整合性、侵入検知エージェントなどの追加の保護ソフトウェアをゴールデンイメージに含みます。
- Amazon Inspector を使用して、脆弱性への準拠について新しい AMI やコンテナイメージをテストします。Amazon Inspector ルールの更新に応じて、既存の AMI やコンテナイメージも定期的に再テストし、新たに見つかった脆弱性の影響から保護します。また、EC2 Image Builder は独自のテストを実行して、機能、互換性、セキュリティコンプライアンスについて AMI を検証することもできます。
- 既知および新たなセキュリティの脆弱性を自動的に修正することもできます。Amazon Inspector サービスを使用して本番環境のサーバーを自動的にスキャンし、セキュリティに関する検出結果を Amazon Simple Notification Service (SNS) トピックに公開できます。次に、これらの通知によってトリガーされる AWS Lambda 関数を作成して検出結果を調べ、問題のタイプに基づいて適切な修復を実装します。
- Systems Manager Session Manager を使用することで、インバウンドポートを開くことなく、安全で監査可能なインスタンス管理が可能となります。

## 頻繁なバックアップを取得する

### 対応する FISC 安全対策基準・解説書の実務基準番号

実 22、実 32

### ベストプラクティス

- 攻撃を受けた場合、バックアップから元のデータを復元する必要があります。定期的にデータのバックアップを取得し、世代管理する事が可能です。頻繁にバックアップし、要件に合わせて保存期間を定めることでコストを限定することも可能です。また、AWS Backup では Vault Lock 機能があり、バックアップデータへの書き込み/編集ができないよう設定が可能です。