1. データ保護的セキュリティ
対象サービス
- AWS Systems Manager
- AWS Secrets Manager
- AWS KMS
- AWS CloudHSM
- Amazon Macie
- (S3)*
- (DynamoDB)*
- (EBS)*
- (EFS)*
- (RDS)*
- (AWS Batch)*
- (AWS Signer)*
*試験ガイド内の"AWSのサービスと機能"には記載なし
AWS Systems Manager
SSM Agent をインストールすることで管理下(マネージドインスタンス)にすることで様々な機能を実行できるようにする
※オンプレミスデバイスにもインストール可能
◆要件
- アウトバンド経路（インターネット経由またはVPCエンドポイント経由）
- IAMロール（AmazonSSMManagedInstanceCore）
SSM Document
実行する処理が書かれているもの（事前定義、自作、共有されたものがある）
※JSON または YAML
Run Command
OS 上でコマンドを実行する（ShellScriptやPowerShellなど）
メリット：リモートアクセスのためのインバウンドポートの解放不要
*インシデント調査とかでOSのプロセスログや情報取得を行うことも可能
Automation
Run Command + AWS サービスの実行が可能（LambdaやAPIなど）
*イレギュラーやルール違反したインスタンスの修復や終了なども可能
Patch Manager
- インスタンスのパッチルールの準拠確認および自動適用が可能
- パッチベースラインを作成することで用途わけが出来る
- 承認プロセスを利用することでパッチ適用有無や検証を行う設定も可能
*最新パッチの未適用インスタンスの発見及び自動対処
※Amazon Inspector と混同しないように注意
Parameter Store
- 設定値の保存が可能
- AMIのIDをパブリックぱあめーたとして利用可能
- 機密情報の場合は KMS を利用して暗号化が出来る
- CloudFormationやECSで環境変数に利用可能
AWS Secrets Manager
シークレットの管理サービス
- DBサービスとの連携
- Amazon RDS データベース (Aurora を含む)
- Amazon DocumentDB データベース
- Amazon Redshift クラスター
- シークレットにアクセスするためには"secretsmanager:GetSecretValue"が必要
- コンソールやCLIから他リージョンへレプリケーション可能
- Cfn/ECS/EKSなどのクレデンシャルを保存するためによく使われる
- Lambda関数を使用することで自動ローテーションが可能
※RDS/AuroraはLambda関数を使用しないマネージドローテーションが可能 - 削除は7~30日の猶予期間が必要(CloudTrailなどでアクセス有無を確認する)
※CloudTrailでアクセスログ、アクセス許可から対象リソースをチェックする
Parameter Store vs Secrets Manager
保存するパラメータへの詳細なアクセス制御*やシークレットのローテーションが必要な場合は Secrets Managerを利用する
*シークレットのアクセス制御設定や、VPCエンドポイントを利用することで柔軟に制御可能
※パラメータ数 10,000 個の制限で使用可能
Q: Secrets Manager と Parameter Store の違いは何ですか?
AWS シークレットマネージャーは、ローテーション、監査、アクセスコントロールと言った組織でのシークレットのライフサイクルを中央で管理するためのサービスです。Secrets Manager を使うと、シークレットを自動的にローテーションできるようになるので、セキュリティとコンプライアンスの要件を満たすのに役立ちます。シークレットマネージャーは MySQL、PostgreSQL、Amazon Aurora on Amazon RDS への統合を組み込むことができ、これは Lambda 関数のカスタマイズで他のタイプのシークレットにも拡張できます。
AWS Systems Manager Parameter Store には、設定データ管理のためのセキュアで、階層的なストレージがあり、これにはシークレットも含みます。データベース接続タイプ、文字れる、パスワードとライセンスコードはパラメータ値として保存され、監査とアクセスコントロールが可能です。保存された値はプレーンテキストでも暗号化されたデータでも構いません。値はパラメータ固有の名前で参照できます。システムマネージャーパラメータを参照してジェネリック設定と自動化スクリプトを構築して、Amazon ECS や AWS CloudFormation など様々な AWS サービスにわたって使用できます。
AWS KMS
キーワード
KMS
サービス名
AWSマネージドキー
AWSが作成、管理、使用するKMSキー
「aws/サービス名」の形式で特定サービスにのみ使用可能
CMK
直接暗号化/復号する場合は4KBまでのデータのみ
APIリクエストのレート制限
例：DescribeKey request rate: 2000
種類は3つ
- カスタマーマネージドキー
- AWSマネージドキー
- AWS所有のキー（これは基本使わない）
CDK
データを暗号化するキー
データを暗号化するたびに都度発行される
Envelope Encryption
CDKを使用して暗号化する方式
暗号化
- アプリケーションから"GenerateDataKey"オペレーションを使用してCDKの作成
- KMSでCMKが復号
- 復号されたCMKを使用してCDKを暗号化
- アプリケーションにプレーンテキストのCDKと暗号化されたCDKが返却
- プレーンテキストのCDKを使用して対象データを暗号化
- プレーンテキストのCDKとデータを破棄
- 暗号化されたデータと暗号化されたCDKを保管する
復号
- アプリケーションから"Decrypt"オペレーションを使用してKMSからCMKを取得
- 保管していた暗号化されたCDKを復号する
- 復号したCDKを使用して保管していた暗号化されたデータを復号する
エイリアス
別名機能
アカウント、リージョンで一意
一つのCMKに複数のエイリアスを設定可能
鍵の種類
- 非対称KMSキー
- Hash-based Message Authentication Code (HMAC) KMS キー ※KMS 内で HMAC を生成して検証するために使用される対称キー
- マルチリージョンキー ※カスタムキーストアでは作成できない、作成時のみ選択可能
→インポートキーを利用する場合、レプリカとプライマリに同様のキーマテリアルをインポートする必要がある
※インポートキーは対象暗号化KMSキーのみに対応
AWSマネージドキー vs CMK
AWSマネージドキーは特定サービスでのみ使用される
作成、管理はAWSが行い、削除は不可（1年での自動ローテーション）
キーローテーション
※自動キーローテーションは対象暗号化KMSキーのみ対応（マルチリージョンでも可能）※インポートしたキーは対象外
手動キーローテーション
エイリアス機能を使用していると楽にできる
対象暗号化KMSキー以外のものや1年以内にローテーションさせたい場合に有効
※この際元のキーを必ず有効なままにしておく（元の暗号化データを復号するようにするため）
削除方法
削除したCMKをもとに戻すことにはできない
削除猶予期間が必須で7~30日
削除時はキーの過去の使用状況を確認する必要がある
- キーのアクセス許可
- CloudTrailからの使用状況
https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/deleting-keys-determining-usage.html
マルチリージョンキーの削除の場合、すべてのレプリカキーを削除する必要がある
※デフォルトではマスターキーは削除されないためレプリカキーを再作成することが可能
アクセス管理
KMSキーのリソースベースポリシー
IAMでのアクセス権限制御
許可(Grant)
→CMK/許可する対象/許可するアクションを指定して一時的なアクセス権を付与する
必要API
データの暗号化について必要なもの
GenerateDataKey
(GenerateDataKeyWithoutPlaintext)
Encrypt
ReEncrypt
Decrypt
カスタムキ―ストア
CloudHSM バックドキーストア（カスタムキーストア）
AWS CloudHSM
- FIPS140-2のレベル3に準拠する必要がある場合に利用
- VPC内サービス
- KMSのカスタムキーストアに使用可能
- SSL/TLS暗号化、複合処理のオフロード（Webサーバとの連携）
- クラスターに対してHSMインスタンスを作成する（自動でロードバランスされる）
※この際、オートスケーリングは行われない
KMS vs Cloud HSM
VPC の内部で動作を行うか否か
FIPS140-2の準拠（CloudHSMはレベル3、KMSはレベル2）
※カスタムキ―ストアでCloudHSMを使用することが可能
Q: AWS KMS と CloudHSM にはどのような違いがありますか?
CloudHSM では、Amazon Virtual Private Cloud (VPC) でのキーの保存と使用のために、検証済みシングテナント HSM クラスターを利用できます。ユーザーは、AWS とは独立した認証メカニズムで、ユーザーのキーがどのように使われるかについて自分だけのコントロールができます。ユーザーは、Amazon EC2 で実行するアプリケーションを操作するのと同様のやり方で、ユーザーの CloudHSM クラスター内のキーを操作します。CloudHSM を使用して様々なユースケースをサポートでき、これにはデジタル著作権管理、パブリックキーインフラストラクチャー (PKI)、ドキュメントへの署名、また PKCS#11、Java JCE、またはMicrosoft CNG インターフェイスを用いた暗号化機能などを含みます。
AWS KMS では、アプリケーションおよびサポートされている AWS のサービスが世界中の複数のリージョンで使用する暗号化キーを単一のコンソールから作成、制御できます。このサービスは、FIPS 140-2 で検証された、あるいは検証中の FIPS HSM を使用して、キーのセキュリティを保護します。AWS KMS ですべてのキーを一元管理することにより、キーを使用できるユーザーとその条件、更新する時期、管理できるユーザーを設定できます。AWS KMS と CloudTrail との統合により、キーの使用状況の監査が可能になるため、規制およびコンプライアンスの対応をサポートできます。アプリケーションからの AWS KMS の操作は、サービス API を直接呼び出す場合は AWS SDK を用いて行い、クライアント側の暗号化を実行する場合は、AWS KMS と統合されている他の AWS のサービス経由か AWS Encryption SDK を用いて行います。
Amazon Macie
- 機械学習とパターンマッチングで S3 に保存された PII を検出可能
- Organizationと連携することでマルチアカウントでの有効化が可能
- リージョナルサービス
(S3)
暗号化
SSE
- S3管理キーによる暗号化（SSE-S3）
- KMSキーによる暗号化（SSE-KMS）
- 顧客提供キーによる暗号化（SSE-C）
CSE（クライアントサイド暗号化）
- SDK等での暗号化
※デフォルトで適用する設定
オブジェクトロック
別アカウントからのアクセス
- 所有者アカウントで共有先アカウント用のIAMロールの作成
- 共有先アカウントでAssumeRoleできるポリシーを作る
- 共有先アカウントでアクセスするロールを作成しアクセスをする
https://dev.classmethod.jp/articles/how-to-use-s3-cross-account/
ライフサイクルポリシー
※注意
Amazon S3 では、以下のライフサイクル移行はサポートしていません。
以下の移行は できません。
・任意のストレージクラスを S3 Standard ストレージクラスに移行する。
・任意のストレージクラスから Reduced Redundancy ストレージクラス (RRS) への移行。
・S3 Intelligent-Tiering ストレージクラスを S3 Standard – IA ストレージクラスに移行する。
・S3 1 ゾーン – IA ストレージクラスを S3 Intelligent-Tiering、S3 標準 – IA、または S3 Glacier Instant Retrieval ストレージクラスに移行する。
Glacier
長期保存用
- S3 Glacier Instant Retrieval: ミリ秒単位での取得が必要な場合(四半期に1回)
- S3 Glacier Flexible Retrieval: 1~5分で迅速取り出し、5~12時間がデフォルト(半年に1回)
- S3 Glacier Deep Archive: 12時間かかる(1年に1回)
Vault = S3でいうバケット
GUIからの直接アップロードはできない ※API/SDKで実施可能
それかS3からライフサイクルポリシーで移動する
Vault Lock
ロックポリシー
ライフサイクルポリシー的なやつ
オブジェクトをロックできる
S3 Glacier のボールトロックでは、ボールトロックポリシーを使用して、S3 Glacier の各ボールトに対するコンプライアンス管理を簡単にデプロイして適用することができます。Vault Lock ポリシーには「write once read many」(WORM) などのコントロールを指定して、そのポリシーをfuture 編集からロックできます。
- ロックを開始するには、ボールトにボールトロックポリシーをアタッチします。これにより、ロックが進行中の状態に設定され、ロック ID が返されます。ポリシーが進行中の状態である間は、ロック ID の有効期限が切れる前に 24 時間以内に Vault Lock ポリシーを検証する必要があります。データ保管庫が In Progress 状態から抜け出さないようにするには、この 24 時間以内に Vault Lock プロセスを完了する必要があります。そうしないと、Vault Lockポリシーが削除されます。
- ロック ID を使用してロック処理を完了します。ボールトロックポリシーが想定どおりに機能しない場合は、ボールトロック処理を中止して最初からやり直すことができます。S3 Glacier API をボールトのロックに使用する方法については、「」を参照してくださいS3 Glacier API を使用したボールトのロック。
アクセスポリシー
バケットポリシー的なやつ
(DynamoDB)
バックアップ
以下3種類の方法あり
- AWS Backup
- DynamoDB - オンデマンド
- DynamoDB - ポイントインタイムリカバリ
AWS Backup
従来からある「オンデマンドバックアップと復元」が実行される
※以下設定は復元対象外
- Auto scaling policies
- IAM policies
- Cloudwatch metrics and alarms
- Tags
- Stream settings
- Time to Live (TTL) settings
DynamoDB - オンデマンド
テーブルの完全なバックアップを作成して、規制コンプライアンスの要件を満たすために長期間の保存とアーカイブを行うことができる
DynamoDB - ポイントインタイムリカバリ
過去 35 日間の任意の時点にテーブルを復元することができる
(EBS)
暗号化方法
- (AWS KMSでキーを作成する)
- 稼働しているEC2インスタンスを停止する
- EC2インスタンスに紐付いているEBS Volumeを特定する
- EBS VolumeのSnapshotを作成する
- 作成されたSnapshotを暗号化を有効化してコピーする
- コピーしたSnapshotからEBS Volumeを作成する
- EC2インスタンスに紐づいている既存のEBS Volumeをデタッチする
- EC2インスタンスに作成した新たな EBS Volumeをアタッチする
- EC2インスタンスを起動する
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSEncryption.html
※EC2の設定画面からデフォルトの有効化を設定可能
キーペア変更方法（紛失時）
- キーペアを作成する
- EC2の停止
- パブリックキーを置き換える（ユーザデータ）
- EC2起動
パスワード変更
(EFS)
保管時
デフォルトで暗号化設定は有効
※設定は作成時のみ設定可能
使用されるのはKMS（AWSマネージドキーかCMK）
暗号化設定が無効なEFSを暗号化する場合、別の暗号化されたEFSを作成し、DataSyncを使って保存されたデータを転送する
転送中
マウント時にマウントヘルパーを使用することでTLSを有効にすることが可能
(RDS)
※暗号化オプションはDB インスタンスの作成時にのみ有効にすることができ、作成後のインスタンスでは有効にすることができない。暗号化されていないスナップショットのコピーは暗号化することが可能（EBSと同様）
→そのため暗号化してコピーしたスナップショットから暗号化されたインスタンスを復元することが可能
(AWS Batch)
(AWS Signer)*
LambdaやContainerでコード署名を行うサービス
→署名が入っていないものはデプロイできないようにすることが出来る
Discussion