Well-Architected Framework Security Pillar Deep Dive ～セキュリティからはじめるより良い設計～

Well-Architected Framework
Security Pillar Deep Dive
～セキュリティからはじめるより良い設計～
AWS事業本部中山順博

スライドは後で入手することが出来ますので
発表中の内容をメモする必要はありません。
写真撮影をする場合は
フラッシュ・シャッター音が出ないようにご配慮ください

3本セッションについて
• 中級向けのセッションです
• IAMの基本的な機能解説などは「しません」
• セキュリティの基礎やAWSのセキュリティ機能をある程度ご存じであること
を前提としています
• 比較的新しい機能を紹介します
• 関連セッション
• 「AWSでのセキュリティ対策全部盛り[初級から中級まで]」を
Developers.IO 2019 TOKYOで発表しました #cmdevio
• https://dev.classmethod.jp/cloud/aws/developers-io-2019-tokyo-all-security-in-
aws/

4
本セッションは特盛くらいです

5Agenda
• Well-Architected Framework
• 設計原則
• ベストプラクティス
• まとめ

7Well-Architected Frameworkとは？
システム設計および運用に関する考え方・ベストプラクティス
• AWSのソリューションアーキテクトとユーザーの経験に基づく
• 5つの柱でシステムを捉える
（セキュリティ、信頼性、運用性、パフォーマンス、コスト）
• それぞれの柱の考え方に基づいて評価対象のシステムをレビュー（質問形式）
• 詳細はホワイトペーパーを参照
• https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf

8Well-Architected Frameworkとは？
レビューの進め方
• CTO、アーキテクト、開発者、運用チームメンバーなど可能な限り全ての関係
者が参加してもらう
• 必要に応じてソリューションアーキテクトがレビューをサポート
（慣れたらWell-Architected ToolでのセルフチェックもOK）
• W-Aに基づくレビューは監査ではない
（現状を踏まえて今後どうするかを考える機会）
• ビジネス要件を踏まえて改善の優先度を設定
（何を優先するかユーザーが決める必要がある / 全てのベストプラクティスに
準拠する必要はない）
• プロジェクトの早い段階で実施することを推奨
（問題の発生を予防 / もちろんリリース後のアセスメントにも利用可能）

10（セキュリティに関する）設計原則
• Implement a strong identity foundation（強固な認証基盤）
• Enable traceability（トレーサビリティの担保）
• Apply security at all layers（全てのレイヤーの保護）
• Automate security best practices（自動化）
• Protect data in transit and at rest（保存・転送時のデータ保護）
• Keep people away from data（人からデータを遠ざける）
• Prepare for security events（セキュリティイベントに備える）

11強固な認証基盤
認証要素
• 知識、所有、生体の組み合わせ（パスワード認証は「知識」のみ）
IDのライフサイクル管理
• 異動や退職などのイベントに合わせた権限の変更やIDの失効など
認容要素の強度
• パスワードの複雑さ、複製のしにくさ、など
最小権限
• 職務定義とそれに必要な権限

12トレーサビリティの担保
アクティビティの収集
• 例：AWSのAPIに対するリクエストのログ（CloudTrail）
アクティビティの監視、重要なイベントの検知
• 例：インスタンスメタデータから取得したクレデンシャルがVPC外から利用さ
れた
不正なイベントへの対応
• 例：セッションの無効化

13全てのレイヤーの保護
Attack Surface
• 人、ファシリティ、ネットワーク、OS、ミドルウェア、アプリケーショ
ン・・・
• 攻撃者はどこか一つの穴を足がかりに目的を達成しようとする
多層防御
• 恒久的に完全な対策は存在しない
• 複数の対策を組み合わせる必要がある

14自動化
セキュリティイベントへの対応
• 大規模化・高度化する攻撃を一組織だけで対応することは一般的に困難
• 人がボトルネックにならない対策が必要
セキュリティリスクを抑制
• 設計通りに設定されていないリスクを排除（設定を自動化）
• 設計・設定自体が適切でないリスクを排除（評価 / 是正の自動化）

15保存・転送時のデータ保護
データの分類
• 機密性の高いデータに対する要件に合わせるのは効率が悪い
データの保護
• データの重要度に応じて、暗号化 / アクセス制御（権限管理） / トークン化な
どの保護を実施

16人からデータを遠ざける
データを人が直接扱うリスク
• 誤った変更や削除
• 改竄
• クレデンシャルの漏洩 / 搾取からの情報漏洩
ツールを介したデータ利用
• データに対する操作を規定 / 制限することでリスクを回避 / 緩和

17セキュリティイベントに備える
もしセキュリティイベントが起こったら・・・
• イベントの検知／外部からの通報
• 現状調査
• 責任者へのエスカレーション
• 問題の緩和（侵害されたリソースの隔離、サービスの停止など）
• 利用者など利害関係者への報告・広報
• サービスの原状回復、暫定対応
• 根本原因調査および対策
• 被害の補償

18
考えることは腐るほどある

19
ベストプラクティス

20ベストプラクティス
• Identity and Access Management（認証・認可）
• Detective Controls（発見的統制）
• Infrastructure Protection（インフラストラクチャの保護）
• Data Protection（データの保護）
• Incident Response（インシデントレスポンス）

21認証・認可
SEC 1. 認証情報と認証をどのように管理していますか?
SEC 2. 人為的なアクセスをどのように制御していますか?
SEC 3. プログラムによるアクセスをどのように制御していますか?

22認証情報と認証をどのように管理していますか?
 アイデンティティおよびアクセス管理要件を定義する
 AWS ルートユーザーを保護する
 Multi-Factor Authentication (MFA) の使用を義務化する
 アクセスコントロールの義務化を自動化する
 一元化されたフェデレーションプロバイダーと統合する
 パスワード要件を義務化する
 認証情報を定期的にローテーションする
 認証情報を定期的に監査する

23Multi-Factor Authentication (MFA) の使用を義務化する
AWS IAMにおけるMFA
• IAM Userに対して所有物による認証を追加できる
• TOTP(RFC6238)およびU2Fに対応

24
どのように展開するか？

MFAは利用者自身で有効化できる
• iam:CreateVirtualMFADevice / iam:EnableMFADeviceなどの権限が必要
• ポリシー変数を利用して自身のIAM Userのみに許可できる
MFAが追加されていない状態で特権を行使されるリスクは？
• 以下の要素で対応可能
• IAM PolicyのNotAction / Condition要素
• IAM RoleのTrust Policy

自身のMFAデバイスを自己管理する権限
＋（業務で必要な権限を持った）IAM Roleを引き受ける権限
IAM UserがMFAを利用してログインしている場合に
権限を委譲する
IAM UserがMFAを利用してログインしている場合に
権限を委譲する

{
"Sid": "BlockMostAccessUnlessSignedInWithMFA",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListUsers",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
多要素認証を利用してログインしていないとき
これらのアクション「以外」
（MFAデバイスの有効化「以外」）
実行を許可しない
IAM: Allows IAM Users to Self-Manage an MFA Device より抜粋
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam_mfa-selfmanage.html
IAM User

Policy Evaluation Logic
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
Denyが優先

{
"Sid": "AllowIndividualUserToManageTheirOwnMFA",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ResyncMFADevice"
],
"Resource": [
"arn:aws:iam::*:mfa/${aws:username}",
"arn:aws:iam::*:user/${aws:username}"
]
} ログインしているIAM User
およびMFAデバイスに対して
これらのアクション
（MFAデバイスの有効化）
実行を許可する
IAM: Allows IAM Users to Self-Manage an MFA Device より抜粋
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam_mfa-selfmanage.html
IAM User

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
}
多要素認証を利用してログインしてる
IAM Userであれば
特定のAWSアカウントに対して
権限の委譲を許可する
Creating a Role to Delegate Permissions to an IAM User より抜粋
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html
IAM Role

IAM User
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"*"
]
}
]
}
任意のIAM Roleに対して
Assume Roleを実行できる
（IAM Roleに信頼されていることが前提）

Policy Evaluation Logic
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
Trust Policyはリソースポリシーの一種

33アクセスコントロールの義務化を自動化する
マルチアカウント環境におけるIAMの管理

マルチアカウント環境におけるIAMの管理
？！

マルチアカウント管理の課題（の一部）
• 組織のセキュリティポリシーをAWSアカウントに「正しく」反映させること
• Organization SCPによるアカウント単位でのアクセス制御
• IAMの管理者に負担が集中
• Permission boundaryによる権限の委任

AWS Organizations
• 複数のAWSアカウントを集中管理
• 料金の支払およびアクセス制御が可能
• 1つの「組織」を定義し、AWSアカウントを組織に参加させる
• OU（組織単位）でAWSアカウントをグループ化できる
• 組織は階層構造のOUとそれに所属するAWSアカウントで構成される
• OUもしくはAWSアカウントにSCP（サービスコントロールポリシー）を適用
できる
• 上位のOUに割り当てられたSCPは下位のOUに継承される
※ Landing Zoneの考え方に基づき、CloudFormation(StackSet)でIAM Role / Policyを展開するアプローチも考えられるがここでは割愛

AWS Organizations の用語と概念
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_getting-started_concepts.html

Permission Boundary（以降、境界）
• IAM Entity(IAM User / Role)に割り当てることができる追加のポリシー（ポリ
シー自体はManaged Policyとして定義）
• 従来のポリシー（Managed PolicyおよびInline Policy）と境界の両方で許可さ
れたアクションを実行可能

例：境界を応用したIAM管理権限の委譲
• 単純にIAMの管理権限を付与すると、IAM管理者が増えるリスクがある
• 「信頼」できるメンバーは組織内に多くいるわけではない・・・
• 境界を利用してIAM管理の「範囲」を制御できる
• 「特権昇格」を防ぐ
• 境界内での権限付与は委任された管理者の裁量で決定（ここ重要）

ユースケース
とあるチームに対して以下のことを委
任したい
• IAM Userの作成
• チームでの業務に必要な権限の付与

1. メンバー用の境界を定義
メンバーが利用してよい最も広い権限を境界用ポリシーと
して定義
2. IAM管理者用の境界を定義
IAM Entityを作成するときに前の手順で作成した境界用の
ポリシーの設定を条件にした境界用ポリシーを定義し、
IAM管理者に割り当て（境界の設定を強制 etc）
3. IAM管理者用の権限を付与
IAMの管理権限を付与（2のポリシーが最小権限であれば、
ここでは”iam:*”など大雑把に許可してOK）
4. IAM管理者用にIAMの管理を委任
IAM管理者の判断でIAM Userの発行と権限の付与を実施
（境界の設定が必須なので、どのようなポリシーを割り当
てても境界以上の権限は行使できない）

1．メンバー用の境界を定義（例）
{
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"ec2:*",
"iam:ListUsers",
"iam:GetAccountPasswordPolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:ChangePassword",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
}
「アクセス許可の境界を使用した他のユーザーへの責任の委任」の一部を抜粋・改変
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate
チームで必要な権限（最大）を定義
認証情報の自己管理に必要な権限

2．IAM管理者用の境界を定義（例）
{
"Sid": "CreateOrChangeOnlyWithBoundary",
"Effect": "Allow",
"Action": [
"iam:CreateUser",
"iam:DeleteUserPolicy",
"iam:AttachUserPolicy",
"iam:DetachUserPolicy",
"iam:PutUserPermissionsBoundary"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/XCompanyBoundaries"
}
}
}
IAM Userに対する管理操作を行う場合、
指定したポリシーが境界として指定されている必要がある
（手順1で作成したポリシー）

{
"Sid": "NoBoundaryPolicyEdit",
"Effect": "Deny",
"Action": [
"iam:CreatePolicyVersion",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:SetDefaultPolicyVersion"
],
"Resource": [
"arn:aws:iam::123456789012:policy/XCompanyBoundaries",
"arn:aws:iam::123456789012:policy/DelegatedUserBoundary"
]
}
境界用のポリシーの管理を禁止
（手順1および2で作成したポリシー）

{
"Sid": "NoBoundaryUserDelete",
"Effect": "Deny",
"Action": "iam:DeleteUserPermissionsBoundary",
"Resource": "*"
}
ユーザーから境界を削除することを禁止

3．IAM管理者用の権限を付与（例）
{
"Sid": "IAM",
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
}
IAMの管理権限を付与
（境界以上の権限は行使できない）

4．IAM管理者用によるIAM Userの管理
• IAM Userを作成する際などに境界を必ず設定する
• 許可するStatementのConditionで指定されているので、設定しないと作成できない
• どのようなポリシーを割り当てても境界以上の権限を行使することはできない

48人為的なアクセスをどのように制御していますか?
 人為的なアクセス要件を定義する
 最小限の権限を付与する
 各個人に一意の認証情報を割り当てる
 ユーザーライフサイクルに基づいて認証情報を管理する
 認証情報管理を自動化する
 ロールまたはフェデレーションを通じてアクセス権を付与する

49認証情報管理を自動化する
認証情報のライフサイクル
• 入社 / 異動（入） / プロジェクトへの参画など
• IDの発行 / 権限の付与
• プロジェクト内での職務の変更
• 権限の変更
• 退社 / 異動（出） / プロジェクトからの離脱など
• IDの失効 ← やらなくても業務に支障が無いのでサボりがち

Automated IAM User Cleanup
• GitHubで公開
• awslabs/aws-well-architected-labs
• https://github.com/awslabs/aws-well-architected-
labs/tree/master/Security/200_Automated_IAM_User_Cleanup
• 長期間利用されていないユーザー / 認証情報（パスワード・アクセスキー）を
自動で削除 / 無効化 / レポート
• SAMでデプロイ

53ロールまたはフェデレーションを通じてアクセス権を付与する
マルチアカウント管理の課題（の一部）
• 適切に設計しないと認証情報が増える
• 例：（アクセスキー / パスワード / MFA Device）× AWSアカウント

54ロールまたはフェデレーションを通じてアクセス権を付与する
Switch Role
• マネージメントコンソールにログイ
ンしたユーザーがIAM Roleの権限に
切り替えること
• 切り替え元のIAM User / AWSカウ
ントを信頼しているRoleに切り替え
ることが可能
• AWSアカウントを横断できる
Switching to a Role (Console)
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html

55プログラムによるアクセスをどのように制御していますか？
 プログラムによるアクセス要件を定義する
 最小限の権限を付与する
 認証情報管理を自動化する
 各コンポーネントに一意の認証情報を割り当てる
 ロールまたはフェデレーションを通じてアクセス権を付与する
 動的認証を実装する

56動的認証を実装する
STS(Security Token Service)
• 一時的な認証情報をリクエストする
ためのサービス
• IAM Roleが信頼する様々なエンティ
ティに対して一時的な認証情報を発
行
• マネージメントコンソール上でス
イッチロールするためにも利用
STS API Reference
https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html

なぜ認証情報をローテーションするべきなのか？
• 認証情報が漏洩したときに被害を抑止できる
• ローテーションできるようにしておくことが重要
• STSで発行した一時的な認証情報が漏洩した場合
• セッションを無効化することが可能
• 管理者が気がつかなかった場合でも被害はセッションの有効期限まで
• 総当たりなどで突破されるリスクを緩和
• （そもそもシークレットアクセスキーは十分長い）

例：IAM Roleのセッション無効化

一時的な認証情報の取得方法は主に2つ
1. AWS STS API （AssumeRole等）
• 明示的に取得
2. （EC2の場合）Instance Metadata
• Amazon EC2 インスタンスでの一時的な認証情報の使用
• 「インスタンスで実行されるアプリケーション、AWS CLI、Tools for Windows PowerShell コマンドが
インスタンスメタデータから自動的に一時的セキュリティ認証情報を取得できるようになります。一時的
セキュリティ認証情報を明示的に取得する必要はありません。AWS SDK、AWS CLI、Tools for
Windows PowerShell によって自動的に EC2 インスタンスメタデータサービスから認証情報が取得され
て使用されます。」
• https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_use-
resources.html#using-temp-creds-sdk-ec2-instances

Instance Metadata
$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/(Profile name)
{
"Code" : "Success",
"LastUpdated" : "2019-09-02T07:33:18Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "XXXXXXXXXXXXXXXXXXXX",
"SecretAccessKey" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"Token" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"Expiration" : "2019-09-02T14:07:29Z"
}

61発見的統制
SEC 4. セキュリティイベントをどのように検出し、調査していますか？
SEC 5. 新しいセキュリティ脅威に対してどのように防御していますか?

62セキュリティイベントをどのように検出し、調査していますか？
 ログの要件を定義する
 メトリクスの要件を定義する
 アラートの要件を定義する
 サービスとアプリケーションのログ記録を設定する
 ログを一元的に分析する
 主要な指標に関するアラートを自動化する
 調査プロセスを開発する

63サービスとアプリケーションのログ記録を設定する
まずはログの取得から
• ログが無いと何も分からない
AWSで取得できる各種ログ
• CloudTrail
• VPC FlowLogs
• Access Log (CloudFront, WAF, ELB, API Gateway, S3 etc…)
• Audit Log (RDS, Redshift etc…)
• OS / Middleware / Application Log（S3 / Logsなどに保存）

64主要な指標に関するアラートを自動化する
様々なセキュリティイベント
• 特定IPアドレス / 不特定多数から大量のリクエスト (DoS / DDoS)
• マルウェアに感染
• C&Cサーバーへのデータ送信
• 認証情報の漏洩 / 搾取
• 不正ログインの試行
• 他多数・・・

GuardDutyで定義されたイベントを通知
• AWS上のアクティビティを機械学習で分析・脅威検知
• 情報ソースはCloudTrail / VPC Flow Logs / DNS Query
• 検知できるイベントの一覧
• https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-active.html
• 例：Backdoor:EC2/C&CActivity.B!DNS
• 既知のC&Cサーバーのホスト名をDNSに問い合わせ

例：PCI DSS v3.2
• 要件 8.1.6に以下のような要件がある
• 「6 回以下の試行で、ユーザ ID をロックアウトすることによって、アクセス試行の繰り返し
を制限する。」
• 要件通りのロックアウトはできないが、検知は可能
• CloudTrailでマネージメントコンソールの認証エラーを記録
• CloudWatch Logsのメトリクスフィルターで一定頻度の認証エラーを検知
• https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudwatch-alarms-for-
cloudtrail.html#cloudwatch-alarms-for-cloudtrail-signin
{ ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }

67ログを一元的に分析する
様々な分析手段
• Elasticsearch Service、Athena/QuickSight、CloudWatch Insights、3rd Party
(SumoLogic etc)
選択基準
• コスト（料金、学習）、想定利用シーン、サポートするログの形式、など
• 「Amazon Athena,Amazon CloudWatch Logs Insightsの使い分けについて考
えてみる」
• https://dev.classmethod.jp/cloud/aws/how-to-use-amazon-athena-amazon-cloudwatch-logs-
insights/

68ログを一元的に分析する
例：SumoLogic
あやしいAWSコンソールログインを監視するダッシュボードをSumoLogicで作ってみる
https://dev.classmethod.jp/cloud/aws/sumologic_custom_dashboard/
_sourceCategory = cloudtrail
| json "userAgent","errorCode" | json "userIdentity.userName" as userName| parse "¥"eventName¥":¥"*¥"" as event_name
| parse regex field=event_name "^(?<event_type>[A-Z][a-z]+?)[A-Z]"
| count by userName, userAgent, event_type,errorCode
| where _count > 10 | sort _count

69新しいセキュリティ脅威に対してどのように防御していますか?
 組織要件、法的要件、コンプライアンス要件に関する最新情報を入手する
 セキュリティのベストプラクティスに関する最新情報を入手する
 セキュリティ脅威に関する最新情報を入手する
 新しいセキュリティサービスとセキュリティ機能を定期的に評価する
 脅威モデルを使用してリスクを定義し優先順位付けする
 新しいセキュリティサービスとセキュリティ機能を実装する

70組織要件、法的要件、コンプライアンス要件に関する最新情報を入手する
例：PCI DSS 4.0
• 2020年末頃にリリースが予定されている
• NISTのガイダンス (NIST SP 800-63) に基づいてパスワードに関する要件が変
更されるもよう
• パスワードの複雑さ・定期変更の要否、多要素認証について
• 「PCI DSS: Looking Ahead to Version 4.0」
• https://blog.pcisecuritystandards.org/pci-dss-looking-ahead-to-version-4.0
PCI DSS v4.0 will incorporate input received from global PCI SSC stakeholders during the 2017 request for comments
(RFC) period. Some of the specific areas that stakeholders asked PCI SSC to review include:
- Authentication, specifically consideration for the NIST MFA/password guidance
- （以下、割愛）

71セキュリティ脅威に関する最新情報を入手する
Capital Oneにおけるセキュリティインシデントの概要
• 独自運用のWAFで設定不備 / SSRF攻撃を受け、認証情報を窃取
（有効と思われる）対策
• 認証上の不正利用を検知
• S3にバケットポリシーを追加
（特定VPCからのアクセスに限定）
• S3上のデータの識別 / 分類
• IAM Roleの権限最小化
• WAFの独自運用を停止
（サービスの利用など）
SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた
https://piyolog.hatenadiary.jp/entry/2019/08/06/062154

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
• Credentials that were created exclusively for an EC2 instance through an
instance launch role are being used from an external IP address.
（インスタンス起動ロールを通じて EC2 インスタンス専用に作成された認証
情報が外部 IP アドレスから使用されています。）

特定のVPCからのみアクセスを許可するS3 Bucket Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Principal": "*",
"Action": "s3:*",
"Effect": "Deny",
"Resource": ["arn:aws:s3:::examplebucket",
"arn:aws:s3:::examplebucket:*"],
"Condition": {
"StringNotEquals": {
"aws:sourceVpc": "vpc-111bbb22"
}
}
}
]
}
Amazon S3 の VPC エンドポイント用のバケットポリシーの例
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/example-bucket-policies-vpc-endpoint.html

75脅威モデルを使用してリスクを定義し優先順位付けする
脅威モデル？
• 「脅威モデリングは、開発対象のソフトウェアがどのようなセキュリティ脅威
にさらされており、攻略される可能性を持ちうるかを洗い出す活動である。」
• https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/c101.html
• 様々な体系的な手法（例）
• STRIDE
• Spoofing（なりすまし）
• Tampering（改竄）
• Repudiation（否認）
• Information disclosure (privacy breach or data leak)（情報漏洩）
• Denial of service（サービス妨害）
• Elevation of privilege（特権昇格）

76インフラストラクチャの保護
SEC 6. ネットワークをどのように保護していますか?
SEC 7. コンピューティングリソースをどのように保護していますか?

77ネットワークをどのように保護していますか?
 ネットワーク保護要件を定義する
 露出を制限する
 設定管理を自動化する
 ネットワーク保護を自動化する
 検査および保護を実装する
 すべてのレイヤーでトラフィックをコントロールする

78設定管理を自動化する
Firewall Manager
• AWS WAF / Shield Advancedの設定をAWSアカウント横断で展開することが
可能
• OrganizationsおよびConfigの有効化が前提
• Security Groupも新たにサポート
• SecurityGroupの割り当て / 評価 / 未使用やスコープの重複の検出など
• 「AWS Firewall Manager の最新情報 – VPC Security Groups のサポート」
• https://aws.amazon.com/jp/blogs/news/aws-firewall-manager-update-support-for-vpc-security-
groups/

79ネットワーク保護を自動化する
AWS WAF Managed Rule
• AWS WAF自体はセルフサービス（ユーザー自身でルールを定義）
• 一定のスキルが必要
• Managed Ruleとしてパートナーからルールの提供を受けることが可能
• Cyber Security Cloud, F5, Fortinet, Imperva, Trend Micro, Trustwave

80ネットワーク保護を自動化する
DDoSに対する影響の緩和
• StandardとAdvanceの2種類のサービスを提供
• Standard
• CloudFront / Route53のエッジロケーションでL3 / L4レイヤーの攻撃を自動緩和
• 無料 / 設定なし
• Advance
• L7レイヤーへの攻撃の緩和
• DRT(DDoS Response Team)によるサポート（WAFのカスタムルール作成など）
• Cost Protection
• Reporting（CloudWatchメトリクスの有効化 / 通知）

81検査および保護を実装する
Config Rulesによる検査と保護
• Configで管理できるリソースを評価 / 適切な状態へ是正することが可能
• 多数のルールが事前定義済 / Lambdaで独自実装することも可能
• Systems Manager Automation Documentで是正する手順を定義
• 自動的な是正も可能
• 「AWS Config ルールを使用してコンプライアンス違反のリソースを自動的に修正する」
• https://aws.amazon.com/jp/about-aws/whats-new/2019/09/use-aws-config-rules-to-automatically-
remediate-non-compliant-resources/

82検査および保護を実装する
Config Rulesの事前定義済ルール（ネットワーク関連）
• Network and Content Delivery
• alb-http-to-https-redirection-check
• api-gw-cache-enabled-and-encrypted
• api-gw-endpoint-type-check
• cloudfront-viewer-policy-https
• internet-gateway-authorized-vpc-only
• vpc-default-security-group-closed
• vpc-flow-logs-enabled
• vpc-sg-open-only-to-authorized-ports
• vpc-vpn-2-tunnels-up
HTTP から HTTPS へのリダイレクトが
ALBのすべての HTTP リスナーで
設定されているかどうかを確認
任意のIPアドレス (0.0.0.0/0) からのアクセス許可を持つ
セキュリティグループで、
指定したインバウンド TCP / UDP トラフィックのみが
許可されるかどうかを確認
指定されたVPCにのみ
Internet Gatewayがアタッチされているかどうかを確認

83コンピューティングリソースをどのように保護していますか?
 コンピューティング保護要件を定義する
 脆弱性をスキャンし、パッチを適用する
 設定管理を自動化する
 コンピューティング保護を自動化する
 IPS / IDS 等
 攻撃領域を削減する
 OS / Middlewareの管理が不要なサービス（Lambda など）
 マネージドサービスを活用する
 バックアップ、パッチ適用が自動化されているサービスの利用（RDS、DynamoDB など）

84脆弱性をスキャンし、パッチを適用する
パッチ適用の課題（OS / ミドルウェア）
• パッチ適用前の検証コスト
• 優先度をつけて順番に対処したいが、どのように優先度を決めるべきかが難しい
• Systems Manager Patch Manager / Inspectorでも脆弱性の検知は可能だが、
上記の課題が残る

例：FutureVulsによる脆弱性のトリアージ
• リスクを受容できる条件を定義 / フィルタリング
• 攻撃コードの有無 / ネットワーク経由での攻撃可否 / 認証情報の要否等
• パッチが提供されていない脆弱性を一時的に非表示
• パッチが提供されたら再表示することが可能
• DeepSecurity as a Serviceとの連携
• 「検知した脆弱性がDSaaSの侵入防御機能で防御されているかをFutureVulsの画面上に表示」
• FutureVuls > RELEASE NOTE > 2019-09-19 リリース内容
• https://releasenote.vuls.biz/release-note/20190919/

Infrastructure as Code
• 大規模な環境でも、コード化した通りに環境を構築できる
• CloudFormation / Terraform / Ansible 等
• マネージメントコンソールなど対話的な設定方法よりミスをするリスクは軽減できる
• ただし、コードが間違っている / 設計が正しいかは別問題

責任共有モデル
AWSを適切に設定することはユーザーの責任

CloudFormationテンプレートのセキュリティチェックツール（例）
• OSS
• cfn-nag :
https://github.com/stelligent/cfn_nag
https://dev.classmethod.jp/cloud/aws/introduction-cfn-nag/
• 商用製品
• Dome9 (preview) :
https://sc1.checkpoint.com/documents/CloudGuard_Dome9/Documentation/Compliance-
and-Governance/CFTAssessment.html
https://gsl.dome9.com/

cfn-nagの評価対象（例）
• 任意のAction
• 任意のPrinciple
AWSTemplateFormatVersion: "2010-09-09"
Description: A sample template for cfn-nag
Resources:
S3Bucket:
Type: AWS::S3::Bucket
Properties:
BucketName: TestBucket
BucketPolicy:
Type: "AWS::S3::BucketPolicy"
Properties:
Bucket:
Ref: "S3Bucket"
PolicyDocument:
Statement:
-
Action:
- "s3:*"
Effect: "Allow"
Resource: "*"
Principal: "*"

cfn-nagの評価結果（例）
------------------------------------------------------------
cfn-nag.yml
------------------------------------------------------------------------------------------------------------------------
| FAIL F15
|
| Resources: ["BucketPolicy"]
|
| S3 Bucket policy should not allow * action
------------------------------------------------------------
| FAIL F16
|
| Resources: ["BucketPolicy"]
|
| S3 Bucket policy should not allow * principal
Failures count: 2
Warnings count: 0

92データの保護
SEC 8. データをどのように分類していますか?
SEC 9. 保管中のデータをどのように保護していますか?
SEC 10. 伝送中のデータをどのように保護していますか?

93データをどのように分類していますか?
 データ分類要件を定義する
 データ保護コントロールを定義する
 データの識別を実行する
 データストアやデータオブジェクトへのタグ付など
 識別および分類を実装する
 データのタイプを特定する

94識別および分類を実装する
Amazon Macieによるデータ管理
• できること
• データの検出と分類
• データのアクティビティを監視 / 不審なアクティビティ発生時にアラート
• データの可視化（分類、アクティビティ）
分類手法
• コンテンツタイプ / ファイル拡張子 / テーマ / 正規表現 / 個人情報(PII) /
SVMベースの分類
• 「Amazon Macie でデータを分類する」
• https://docs.aws.amazon.com/ja_jp/macie/latest/userguide/macie-classify-data.html

95識別および分類を実装する
クレジットカード情報
個人情報

96保管中のデータをどのように保護していますか?
 保管中のデータの管理と保護に関する要件を定義する
 安全なキー管理を実装する
 保管中に暗号化を適用する
 アクセスコントロールを適用する
 人をデータから遠ざけるメカニズムを提供する

97保管中のデータの管理と保護に関する要件を定義する
暗号化の分類
• サーバーサイド暗号化
• データストア（サーバー）に保存する際に透過的に暗号化
• クライアントサイド暗号化
• アプリケーション（クライアント）がデータストアにデータを送信する前に暗号化

98安全なキー管理を実装する
AWS KMS
• 暗号鍵の作成、管理、運用のためのサービス
• Server-side Encryption
• データの書き込み時に透過的に暗号化
• S3、EBS、RDS、RedShift などのサービスでKMSとの連携をサポート
• https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/service-integration.html
• Client-side Encryption
• ユーザーアプリケーションでの暗号化してからデータを保存
• AWS Encryption SDKでKMSと容易に連携可能

99安全なキー管理を実装する
エンベロープ暗号化
• AWS Encryption SDKで用いられる方式
• AWS KMSやAWS CloudHSM等でマスターキーを管理
• 暗号化
• 保護対象のデータをデータキーで暗号化
• データキーをマスターキーで暗号化
• 複合
• 暗号化されたデータキーをマスターキーで複合
• 暗号化されたデータをデータキーで複合
Envelope Encryption
https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/how-it-works.html#envelope-encryption

100人をデータから遠ざけるメカニズムを提供する
例：認証情報の管理
• Parameter Store / Secret Managerに保管し、アプリケーションが必要なタイ
ミング（起動時など）に参照
• プログラムや設定ファイルへのハードコードによるリスクの緩和
• EC2インスタンスに対してParameter Store等へのアクセス権をIAM Roleで付
与することによるアクセス制御が可能

101人をデータから遠ざけるメカニズムを提供する
例：データベースの接続情報をParameter Storeで管理
Parameter Storeへのアクセス権を定義
IAM Roleを介して
Parameter Storeへのアクセス権を付与
インスタンスメタデータから認証情報を取得して
Parameter Storeから接続情報を読み取り

102伝送中のデータをどのように保護していますか?
 伝送中のデータの保護に関する要件を定義する
 安全な鍵および証明書管理を実装する
 伝送中に暗号化を適用する
 データ漏洩の検出を自動化する
 ネットワーク通信を認証する

103安全な鍵および証明書管理を実装する
Certification Managerによる証明書管理
• 無償でサーバー証明書を発行 / 管理
• ただし、CloudFront / ELB / API Gatewayとの連携が前提
（EC2インスタンスに直接展開することはできない）
• EV証明書は別途調達してインポートする必要あり
• Private CAは有償

104伝送中に暗号化を適用する
あらかじめ作成 / インポートした証明書を選択するだけ

HTTPSリスナーへのリダイレクト

より安全な暗号化プロトコルの利用
• 「Application Load Balancer および Network Load Balancer に、より厳格な
プロトコルと暗号を使用した Forward Secrecy 向けの新しいセキュリティポ
リシーを追加」（2019年10月8日）
• https://aws.amazon.com/jp/about-aws/whats-new/2019/10/application-load-balancer-
and-network-load-balancer-add-new-security-policies-for-forward-secrecy-with-more-
strigent-protocols-and-ciphers/
• より厳格なセキュリティ要件に対応
• ELBSecurityPolicy-FS-1-2-2019-08 / ELBSecurityPolicy-FS-1-1-2019-08 /
ELBSecurityPolicy-FS-1-2-Res-2019-08
• “This policy (ELBSecurityPolicy-FS-1-2-Res-2019-08) supports TLS 1.2 only and includes
only ECDHE (PFS) and SHA256 or stronger (384) ciphers.”

AWS Site-to-Site VPN
• IPsecをサポート

108ネットワーク通信を認証する
インターネットVPN（サイト間VPN接続もアップデート）
• 2019年8月16日にVPN接続の認証でACMのPrivate CAから発行したプライベー
ト証明書の使用をサポート
• 「AWS サイト間 VPN で証明書による認証のサポートを開始」
• https://aws.amazon.com/jp/about-aws/whats-new/2019/08/aws-site-to-site-vpn-now-supports-
certificate-authentication/
• 概要
• カスタマーゲートウェイを作成するときに証明書を指定（以前は事前共有キー）
• Service Linked Roleが必要
• カスタマーゲートウェイデバイスのIPアドレスを指定する必要がない
（固定のグローバルIPは不要）
「Site-to-Site VPN Tunnel Authentication Options」
https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-tunnel-authentication-options.html#certificate

109インシデントレスポンス
SEC 11. セキュリティインシデントにどのように対応していますか?

110セキュリティインシデントにどのように対応していますか？
 重要な人員と外部リソースを特定する
 ツールを特定する
 インシデント対応計画を策定する
 封じ込め機能を自動化する
 フォレンジック機能を確認する
 アクセスを事前準備する
 ツールを事前デプロイする
 ゲームデーを実施する

111インシデント対応計画を策定する
もしセキュリティイベントが起こったら・・・
• イベントの検知 / 外部からの通報
• 現状調査
• 責任者へのエスカレーション
• 証拠の保全 / 問題の緩和
（侵害されたリソースの隔離、サービスの停止、認証情報の無効化、など）
• 利用者など利害関係者への報告・広報
• サービスの原状回復、暫定対応
• 根本原因調査および対策
• 被害の補償

112重要な人員と外部リソースを特定する
ずべて自分たちだけで対応できますか？
• 証拠の保全やそれを利用した根本原因の調査
• 外部の専門家へ依頼
• 利害関係者への報告
• 経営者や広報との調整
• 被害の補償
• 弁護士へ対応を委任
• 保険会社へ保険金の請求

113ツールを特定する
自分たちでできることは？
• ログの収集、分析
• 各種ログの収集と分析
• イベントの検知
• Guard Duty / Shield Anvanced / WAF 等だけでなく、Abuse Reportも確認
• リソースの隔離
• Network ACL・Security Groupなどで隔離する手順を予め確立
• メモリ上の情報を保全することも重要
（停止させずにサービスへの影響を排除することも重要）
• 事前準備内容の評価

114ゲームデーを実施する
ゲームデーとは？
• AWS環境が与えられる
• そこに攻撃や障害など様々なイベントが発生
• 環境を維持することでポイントが貰えるので、チームでポイントを競う
• 詳しくはこちら
• 「AWS GameDayに初参加してみた【AWS GameDay Microservices Madness@AWS Loft
Tokyo】」
• https://dev.classmethod.jp/etc/aws-gameday-microservices/

116まとめ
体系的な手法で現状と課題を明確化
• Security外の柱でも評価してみましょう
ビジネス要件を踏まえて優先度を設定
• 投資できる費用や優先すべき課題はビジネスによって異なる
• ビジネス環境自体も変化する
継続的な評価と改善
• 定期的にレビューし、AWSのアップデートや脅威のトレンドを踏まえた改善を

Well-Architected Framework Security Pillar Deep Dive ～セキュリティからはじめるより良い設計～

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Well-Architected Framework Security Pillar Deep Dive ～セキュリティからはじめるより良い設計～

Similar to Well-Architected Framework Security Pillar Deep Dive ～セキュリティからはじめるより良い設計～ (20)

More from Nobuhiro Nakayama

More from Nobuhiro Nakayama (20)

Well-Architected Framework Security Pillar Deep Dive ～セキュリティからはじめるより良い設計～