AWS公式資料で挑むSCS認定(33)-こんな時どうする(全分野その10)

[前回] AWS公式資料で挑むSCS認定(32)-こんな時どうする(全分野その9)

はじめに

今回も引き続き、「こんな時どうする」集の作成です。

分野1: インシデント対応

• Amazon S3バケットへの不正アクセスが報告された、S3バケットに保存された大量データに意図しない機微情報が含まれていないか確認したい
  • Amazon Macieを使用し、S3バケットに機微情報が含まれていたら検出
  • ※ Amazon Macieはデータセキュリティとデータプライバシーのフルマネージドサービスで、機械学習とパターンマッチングを使用しAWS上の機密データを検出して保護する
  • ※ Amazon Macieが解決する課題
    • アカウント内のS3バケットの利用状況の可視化、格納されている大量オブジェクトの可視化
    • 設定に基づき、指定されたバケット内の機微情報の評価・検出を効率的に実行
    • 評価・検出結果の参照、他のサービスへの連携
  • ※ Macieの利用ステップ
    • 管理者がS3バケットの状態をAWSマネジメントコンソールで確認
      • S3バケットの設定に対する変更はFindingsで検出可能
    • スキャンが必要なバケットを指定
    • スキャンジョブを作成する
      • ジョブはスキャン対象バケットの設定とスケジュールのセット
      • 指定したスケジュールで自動的にジョブが実行される

分野2: ログとモニタリング(監視)

• SAML 2.0フェデレーション用にIAMロールを作成したい
  • SAML用ロールを作成するための前提条件
    • ①IAM SAML IDプロバイダーを作成し、SAML 2.0 IdPとAWS間の信頼関係を記述
    • ②SAML 2.0認証ユーザーが引き受けるロールのポリシーを準備
      • 1つは、ロールの引き受け先を指定するロール信頼ポリシー
        • Action要素: sts:AssumeRoleWithSAML
        • Principal要素: {"Federated":①で作成したSAML 2.0 IdPのARN}
        • Condition要素: StringEquals条件で、SAMLレスポンスからのSAML:aud属性がAWSのSAMLフェデレーションエンドポイントと一致するかチェック
          • 例: {"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}
      • もう1つは、IAMアクセス許可ポリシー
        • フェデレーティッドユーザーにアクセスを許可/拒否するAWSアクション/リソースを指定
  • SAML用IAMロールの作成
    • AWS Management Consoleにサインインし、[ロールの作成]を選択
    • [SAML 2.0 フェデレーション]ロールタイプを選択し、[SAML プロバイダー]で、ロールのプロバイダーを選択
    • SAML 2.0のアクセスレベルメソッドを選択
      • [プログラムによるアクセスのみを許可する]を選択すると、プログラムがAWS APIまたはAWS CLIを使って引き受けられるロールを作成
      • [プログラムによるアクセスと AWS Management Console によるアクセスを許可する]を選択すると、AWS Management Consoleまたはプログラムにより引き受けられるロールを作成
      • プログラムのアクセス用ロールを作成する場合、[属性]リストから属性を選択し、[値]ボックスでロールに追加する値を入力
        • 指定した属性により、ロールアクセスはSAML認証応答(アサーション)に含まれるIDプロバイダーのユーザーのみに制限される
      • いずれのアクセスレベルメソッドも、信頼ポリシーに以下特定条件を含む
        • SAML対象者SAML:aud属性がSAMLのAWSサインインエンドポイントhttps://signin.aws.amazon.com/samlに設定されているかチェック
    • SAML 2.0の信頼情報を確認し、[Next: Permissions (次へ: アクセス許可)]を選択
      • 前提条件で作成したポリシーを、アクセス許可ポリシーとして選択するか
      • [ポリシーの作成] を選択して、新しいポリシーをゼロから作成
    • ウェブIDユーザーに許可するアクセス許可ポリシーの横にあるチェックボックスをオンに設定
    • (オプション)アクセス許可の境界を設定(アドバンスト機能)
      • [Set permissions boundary(アクセス許可の境界の設定)]セクションを開き、[Use a permissions boundary to control the maximum role permissions (アクセス許可の境界を使用してロールのアクセス許可の上限を設定する)] を選択
      • アクセス許可の境界として使用するポリシーを選択
    • ロールの作成後に、IDプロバイダーソフトウェアを設定し、SAML信頼を確立(IdPとAWSの証明書利用者信頼の設定と呼ばれる)
      • 設定に必要な情報には、フェデレーティッドユーザーで使用するIAMロールが含まれる

分野3: インフラストラクチャのセキュリティ

• AWS Artifactの監査アーティファクトを、監査人と共有したい

  • AWS Artifactの監査アーティファクトレポートへのアクセス権限を監査人に付与
    • 各監査人専用のIAMユーザー認証情報を作成
    • 監査人の監査に必要なレポートのみアクセスできるように、アクセス権限を付与

• 企業内アプリケーションとAWS S3間でデータ転送が必要だが、インターネット接続が不安定

  • AWS Direct Connect + VPN構成を使用し、AWS Direct Connect専用ネットワーク接続とAWS VPNを組み合わせる
    • 安全で高速なネットワークを構築でき、帯域幅のスループットを向上させる
    • インターネットベースの接続より一貫したネットワークエクスペリエンスを利用できる
  • ※ AWS Direct ConnectのパブリックVIFは、リモートネットワークとパブリックIPで提供されるAWSサービス(S3やDynamoDB)の間に、IPsec VPNなど専用ネットワーク接続を確立
    • パブリックVIFは、リモートネットワークとAWSをパブリックIPでつなぐもの
  • ※ AWSホワイトペーパーAmazon Virtual Private Cloud Connectivity Optionsを参照

• 開発チームで安全なクラウドアーキテクチャを構築したい

  • AWS Artifactの監査アーティファクトの一部として提供される、責務についてのガイダンスを使用する
  • ガイダンスの内容
    • ISO、PCI、SOCなど規制標準の準拠における、システム開発担当者の責任
    • システム固有のユースケースに対応するため、追加で実行すべきセキュリティ制御
  • ※ AWS Artifact Reportsは、次のような場合に使用できる
    • システム設計、開発、監査のライフサイクルで、クラウドアーキテクチャのコンプライアンスを実証する義務がある場合
    • AWSインフラストラクチャの過去および現在のコンプライアンスを実証するため、監査人や規制機関へ証拠を提出する必要がある場合
    • AWSに実装したセキュリティ制御が効果的に動作しているかを検証したい場合
    • サプライヤーを継続的にモニタリングまたは監査する必要がある場合

分野4: アイデンティティ(ID)及びアクセス管理

• IAMによるアクセス制御(認可)において、どのような順番でアクセスが許可/拒否されるか知りたい
  • 暗黙的Deny
    • 最小権限の原則により、すべてのアクセスをデフォルトで拒否
  • Allowによる許可
    • アクセス権限にAllow条件があった場合、アクセス許可
  • 明示的Deny
    • アクセス権限に1つでもDeny条件があった場合、アクセス拒否

分野5: データ保護

• KMSキーを安全に使用するためアクセス制御を行いたい
  • ポリシーの種類
    • キーポリシーによるリソースベースアクセス制御
      • 暗号キー作成時にキーポリシーが定義される
      • AWS管理コンソール、CLI/SDKによりポリシー変更可能
        • GetKeyPolicy: ポリシーの取得
        • PutKeyPolicy: ポリシーの設定
    • IDベースアクセス制御
      • IAMユーザーやIAMロールで設定されたポリシーによるアクセス制御
  • ポリシーの評価
    • 暗号キーに付与されたリソースベース権限と、IAMユーザー/ロールに付与したユーザーベースの権限、両方を評価
    • 暗号キーに付与されるデフォルトキーポリシー
      • KMSキーを所有するAWSアカウントにKMSキーへのフルアクセスを付与
        • "Principal": {"AWS": "arn:aws:iam::account-ID:root"}
      • このキーポリシーにより、アカウントはIAMポリシーを使用し、キーポリシーに加えKMSキーへのアクセス許可を行える
      • AWSアカウントの削除できないルートユーザーを含むアカウント管理者に、アクセス許可を付与することで、キーが管理不能になるリスクを軽減
  • 許可(Grants)
    • キーポリシーの他に、許可(Grants)というリソースベースのアクセス制御機能をサポート、より細かいアクセス権の設定が可能
    • 許可(Grants)を使用し、クライアントにより他のAWSプリンシパルへKMSキー使用を委任できる

おわりに

「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。

[次回] AWS公式資料で挑むSCS認定(34)-こんな時どうする(全分野その11)