元情シス部員の頑張るIT

元情シスで現コンサルでもうすぐ転職。少しは使えるようになりました。

AWS Certified Security - Specialty の勉強メモ - 5

はじめに

  • 今週からまたテストを繰り返し実施
  • 間違えた問題を適宜フォローする
  • ただ、明日からProgritが始まるので時間がない気がする・・・

間違えた問題

MFAがない場合にアクセスさせないIAMロール

  • Boolで囲んでMFAかどうかチェックさせる
{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": [
            "service-prefix-1:*",
            "service-prefix-2:action-name-a",
            "service-prefix-2:action-name-b"
        ],
        "Resource": "*",
        "Condition": {
            "Bool": {"aws:MultiFactorAuthPresent": true},
            "DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"},
            "DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"}
        }
    }
}

KMSと統合されたAWSサービスがキーを利用するための設定

  • GrantISForAWSResourceをつける
{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:user/ExampleUser"
  },
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "kms:GrantIsForAWSResource": true
    }
  }
}

暗号化キーを排他的に管理する

  • CloudHSMを使う（わかっていたけど何故か間違い・・・）

CLIでのawskmsdecrypt

  • KeyIDは必須ではない
  • が公式ドキュメントには以下の記載あり

    暗号文が対称CMKで暗号化されている場合、KeyIdパラメーターはオプションです。AWS KMSは、対称暗号文ブロブに追加するメタデータからこの情報を取得できます。この機能は、CMK IDを見失った場合でも、許可されたユーザーが暗号化されてから数十年後に暗号文を復号化できるようにすることで、実装に耐久性を追加します。ただし、ベストプラクティスとしてCMKを指定することを常にお勧めします。KeyIdパラメーターを使用してCMKを指定すると、AWSKMSは指定したCMKのみを使用します。暗号文が別のCMKで暗号化されている場合、復号化操作は失敗します。この方法により、意図したCMKを確実に使用できます。

  • Key IDは入れたほうが良いとのこと
  • コマンドリファレンスは以下
  decrypt
--ciphertext-blob <value>
[--encryption-context <value>]
[--grant-tokens <value>]
[--key-id <value>]
[--encryption-algorithm <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]

decrypt — AWS CLI 1.19.49 Command Reference

インポートしたCMKのローテーション

  • インポートしたCMKは自動ローテーションできないので手動でやる必要がある

    新しい CMK を作成し、元の CMK の代わりに使用することを決める場合があります。これには、既存の CMK のキーマテリアルをローテーションするのと同じ効果があり、多くの場合、手動キーローテーションとみなされます。キーローテーションのスケジュールを制御する場合は、手動ローテーションすることをお勧めします。またCMKs、非対称 CMKs CMKs、カスタムキーストア内CMKs、インポートされたキーマテリアルを含む、自動キーローテーションの対象ではないローテーションの方法も提供します。

カスタマーマスターキー ローテーション - AWS Key Management Service

  • 手動でやる場合は、まず新しいCMKをインポートしてエイリアスを付け替えることで対応
  • 古いCMKを削除してしまうと元のCMKで暗号化したデータが復号化できなくなるので削除期間を設ける

ConfigのカスタムルールでフックするLambda

  • カスタムルールを作ったとき、トリガーするLambdaを設定できる
  • Lambdaによってリソースの変更を基に戻すなどの対応を自動化できる
  • SSMではない

AWS Config Custom Rules - AWS Config

その他考え方

  • CLIよりLambdaのほうが費用対効果が高いとされている？物によるかも