[前回] AWS公式資料で挑むSCS認定(31)-こんな時どうする(全分野その8)
はじめに
今回も引き続き、「こんな時どうする」集の作成です。
分野1: インシデント対応
- ウェブサイトの特定ページに大量リクエスト発生、アクセス制限したい
- AWS WAFのレートベースのルールを使用し、ウェブサイト特定ページへのアクセスを制限
- レートベースのルールに文字列一致条件を追加し、ログインページへのリクエストを制限する例
- リクエストを「URI」を用いてフィルターリング
- 一致の種類は「で始まる」
- 一致する値は「/login」(リクエストURI部分のログインページを識別するもの)
- レート制限を5分あたりxxx回リクエストと指定
- レートベースのルールをウェブACLに追加し、残りのサイトに影響することなく、IPアドレスごとにログインページへのリクエストが制限される
分野2: ログとモニタリング(監視)
- Amazon S3バケットにコンプライアンス違反のアクセス許可が設定されていたら通知したい
- AWS Trusted Advisorを使って、S3にオープンアクセス許可を持つバケットがないかチェック
- バケットの「リスト」 アクセスを全員に許可してしまうと、予想より多くの料金が発生する可能性あり
- バケットの「アップロード/削除」 アクセスを全員に許可した場合、セキュリティ脆弱性の原因となる
- Amazon S3のイベント通知機能を使用し、S3バケットでPUT、POST、DELETEイベントが発生したときに通知するように設定
- Amazon S3のCloudTrail証跡を作成し、CloudWatchのイベントルール設定で「S3バケットの作成と修正」イベントを通知するように設定
- AWS Trusted Advisorを使って、S3にオープンアクセス許可を持つバケットがないかチェック
分野3: インフラストラクチャのセキュリティ
-
Amazon EC2 Auto Scalingで使用するAMI/EBSを、KMSキー(カスタマー管理キー)を使って暗号化したい
- Amazon EC2 Auto Scalingは、サービスリンクされたロール(SLR)を用いて他のAWSサービスへの呼び出しを許可される
- SLRの許可はAWSによってハードコードされ変更できない
- デフォルトで、Amazon EC2 Auto Scaling SLRに提供された許可に、AWS KMS キーにアクセスするための許可が含まれていない
- AWS管理キーまたはカスタマー管理キー(KMSキー)を使用し、Amazon EC2 Auto Scalingを使用するAmazon Elastic Block Store(Amazon EBS)のボリュームまたはAMI を暗号化できる。Amazon EC2 Auto Scalingに追加が必要な許可
- AWSマネージドキーは、追加不要
- カスタマー管理キーは、追加要
- Amazon EC2 Auto Scalingは、サービスリンクされたロール(SLR)を用いて他のAWSサービスへの呼び出しを許可される
-
Amazon EC2 Auto Scalingで同じAWSアカウントのカスタマー管理キーを使用したい
※注意: 123456789012は、Amazon EC2 Auto ScalingグループがデプロイされているアカウントID
{
"Sid": "Allow service-linked role use of the KMS",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
]
},
"Action": [
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": true
}
}
}
- Amazon EC2 Auto Scalingで、外部AWSアカウントのカスタマー管理キーを使用したい
ステップ1. キーポリシーでCreateGrant
アクションを許可し、外部AWSアカウントに存在するIAMエンティティにアクセス権限を付与
{
"Sid": "Allow external account 111122223333 use of the KMS",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources in external account 111122223333",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Action": [
"kms:CreateGrant"
],
"Resource": "*"
}
ステップ2. Amazon EC2 Auto ScalingグループがデプロイされているAWSアカウントのIAMエンティティの認証情報を用いて、AWS CLIコマンドcreate-grant
を実行
※ 注意: 444455556666 は、KMSキーが存在するアカウントID
$ aws kms create-grant --key-id arn:aws:kms:us-west-2:444455556666:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d --grantee-principal arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling --operations Decrypt GenerateDataKeyWithoutPlaintext ReEncryptFrom ReEncryptTo CreateGrant
ステップ3. IAMエンティティにCreateGrant
アクセス許可がない場合、IAMエンティティにアタッチされたポリシーに次のステートメントを追加
{
"Sid": "AllowCreationOfGrantForTheKMSinExternalAccount444455556666",
"Effect": "Allow",
"Action": "kms:CreateGrant",
"Resource": "arn:aws:kms:us-west-2:444455556666:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d"
}
※ 引用元: https://aws.amazon.com/jp/premiumsupport/knowledge-center/kms-launch-ec2-instance/
分野4: アイデンティティ(ID)及びアクセス管理
- IAMユーザーを新規作成せず、社内既存のActive DirectoryユーザーIDとActive Directory Federation Servicesを使ってAWSサービスを利用したい
- SAML 2.0フェデレーションを使用し、IDプロバイダー(IdP)管理の外部ユーザーIDにAWSリソースへのアクセス許可を付与
- SAML 2.0フェデレーション用にIAMロール作成が必要
- ※ AWSは、多くのIdPのオープンスタンダードであるSAML 2.0を使用したIDフェデレーションをサポート
- フェデレーティッドシングルサインオン(SSO)が有効であるため、組織内ユーザー全員に対しIAMユーザーを作成しなくても、ユーザーがAWS Management Consoleにログインしたり、AWS APIオペレーションを呼び出したりできる
- SAMLを使用すると、カスタムIDプロキシコードの書き込みの代わりにIdPのサービスを使用できるため、AWSを使用してフェデレーションを構成するプロセスを簡素化できる
- ※ SAML(Security Assertion Markup Language)とは、1つのIDとパスワードで認証を行うSSO(シングルサインオン)を実現する仕組みのひとつ
- 異なるインターネットドメイン間でユーザー認証を行うためOASISによって策定された認証情報の規格
- 信頼性を確保するため、SAMLアプリケーションでは証明書を使用
- ※ SAML認証フロー
- ユーザーはログイン(SSO)のため、SP(AWSなどサービスプロバイダー)へアクセス
- SP(AWS)がユーザーから渡されたSAMLアサーション(認証情報/ユーザー属性)でSAML認証要求を作成
- SPがユーザーのアクセスをSAML認証要求とあわせてIdPへ送る
- IdPは認証情報を提供するシステムで、SAML認証要求に対し、適切なユーザーか、以前登録したユーザーか、確認
- IdPがSAML認証応答を作成、SAML認証応答には認証結果が含まれる
- SPが受け取ったSAML認証応答にもとづいて、ユーザーのログインを許可/拒否
- フェデレーションとは、パスワードの代わりにチケットと呼ばれる情報をクラウドサービス間で受け渡しすることでSSOを実現する方式で、多くのSPで使用
- フェデレーション方式に使えるプロトコルは、SAMLやOpenID Connect
分野5: データ保護
-
EC2インスタンスのアプリケーションからS3 APIを使って安全にS3バケットにアクセスしたい
- Amazon S3にアクセスするための適切なアクセス権限を持つIAMロールを作成
- アクセス許可ポリシーは
AmazonS3ReadOnly
をアタッチ
- アクセス許可ポリシーは
- EC2インスタンスを起動し、IAMロールをアタッチ
- アプリケーションからIAMロール提供の認証情報を使用しS3バケットにアクセス
- Amazon S3にアクセスするための適切なアクセス権限を持つIAMロールを作成
-
EC2インスタンのアプリケーションから新規作成のKMSキーを使って暗号化/復号したい
- EC2インスタンスにアタッチされたIAMロールのポリシーに、リソースへの
kms:Encrypt
とkms:Decrypt
アクションを許可 - AWS KMS用のVPC エンドポイントを作成し、EC2インスタンスからAWS KMS APIをコールするように
- AWS KMSで、KMSキーのキーステータスを有効(Enabled)に設定
- AWS KMSで、KMSキーポリシーにIAMロールからのアクセス許可を追加
- EC2インスタンスにアタッチされたIAMロールのポリシーに、リソースへの
おわりに
「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。