AWS Well-Architected Tool 活用術セミナー セキュリティ編

1. AWS Well-Architected Tool 活用術セミナー
セキュリティ編
2019/09/05
Nobuhiro Nakayama
1

2. 2Agenda
• 設計原則
• ベストプラクティス
• まとめ

3. 3
設計原則

4. 4設計原則
• 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（セキュリティイベントに備える）

5. 5
ベストプラクティス

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

7. 7
難しめの質問事項を中心に解説

8. 8認証・認可
SEC 1: How do you manage credentials and authentication?
（認証情報と認証をどのように管理していますか？）
SEC 2: How do you control human access?
（人によるアクセスをどのように制御していますか？）
SEC 3: How do you control programmatic access?
（プログラムによるアクセスをどのように制御していますか？）

9. 9認証情報と認証をどのように管理していますか？
□ アクセス要件を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義している
□ ルートユーザにMFA(多要素認証)を設定、アクセスキーを削除し、最小限の利用に留めている
□ MFA(多要素認証)を強制している
□ ツールなどを用いてアクセス制御を自動化している（Organizations SCP など）
□ IDプロバイダもしくはディレクトリサービスを使用している
□ 適切なパスワード要件を強制している
□ 認証情報を定期的にローテーションしている(退職者などの不正利用防止)
□ 定期的に認証情報の監査を行っている(アクセス要件、MFA、ローテーションなどの確認)

10. 10人によるアクセスをどのように制御していますか？
□ 人為的なアクセス要件を適切に定義している(不要な特権アクセスのリスクを軽減)
□ 最小限の権限を付与している
□ 各個人に固有の認証情報を割り当てている
□ ユーザーのライフサイクルに基づいて認証情報を管理している(退職者の情報削除など)
□ 認証情報管理を自動化している
□ ロールまたはフェデレーションを介してアクセスしている

11. 11Automated IAM User Cleanup
Level 200: Automated IAM User Cleanup
https://github.com/awslabs/aws-well-architected-labs/tree/master/Security/200_Automated_IAM_User_Cleanup

12. 12Automated IAM User Cleanup

13. 13プログラムによるアクセスをどのように制御していますか？
□ プログラムにアクセス要件を適切に定義している(不要な権限によるアクセスのリスクを軽減)
□ 最小限の権限を付与している
□ 認証情報管理を自動化している(動的認証の管理やレポートなど)
□ 各コンポーネントに固有の認証情報を割り当てている(LambdaとEC2でIAMロールを分けるな
ど)
□ ロールまたはフェデレーションを介してアクセスしている
□ 動的認証を実装している(認証情報を動的に取得し、自動的にローテートされる)

14. 14STS(Security Token Service) による一時認証情報の発行
STS(Security Token Service)とは
• 一時的な認証情報をリクエストするための
サービス
• フェデレーションを実現するために利用
• マネージメントコンソール上でスイッチ
ロールするためにも利用
STS API Reference
https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html

15. 15Switch Role
Switch Roleとは
• マネージメントコンソールにログインした
ユーザーがIAM Roleの権限に切り替えるこ
と
• 切り替え元のIAM User / AWSカウントを
信頼しているRoleに切り替えることが可能
Switching to a Role (Console)
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html

16. 16Instance Profile / Instance Metadata
Instance Profileは、インスタンスにIAM Roleの一時的な認証情報を渡すために利用
一時的な認証情報はInstance Metadata経由で取得
AWS CLI / SDKをインスタンス上で利用する場合、認証情報の取得を意識する必要はない
$ 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"
}
Retrieving Security Credentials from Instance Metadata
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials

17. 17発見的統制
SEC 4: How do you detect and investigate security events?
（セキュリティイベントの検知と調査をどのように行っていますか？）
SEC 5: How do you defend against emerging security threats?
（新たに発生するセキュリティ上の脅威にどのように対応していますか？）

18. 18セキュリティイベントの検知と調査をどのように実施していますか？
□ ログの要件を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義している
□ メトリクスの要件を適切に定義している
□ 通知の要件を適切に定義している
□ アプリケーションログやAWSサービスのログなどワークロード全体のログを取得している
□ ログを一元的に分析している
□ 重要なメトリクスやイベントの監視と通知を行っている
□ インシデント対応のために、エスカレーションパスも含めた調査プロセスが確立している

19. 19AWS上でのアクティビティ
AWS上での様々なアクティビティを収集できる
• CloudTrail
• VPC FlowLogs
• Access Log (CloudFront, WAF, ELB, API Gateway, S3 etc…)
• Audit Log (RDS, Redshift etc…)
• OS / Middleware / Application Log（S3やCloudWatch Logsへ保存）

20. 20ログの集約と分析
Centralized Logging
https://aws.amazon.com/solutions/centralized-logging/

21. 21GuardDuty
GuardDutyにより不審なアクティビティを検知（脅威インテリジェンスの利用）
• 検知可能なアクティビティの例
 Backdoor Finding Types
 Behavior Finding Types
 CryptoCurrency Finding Types
 PenTest Finding Types
 Persistence Finding Types
 Policy Finding Types
 PrivilegeEscalation Finding Types
 Recon Finding Types
 ResourceConsumption Finding Types
 Stealth Finding Types
 Trojan Finding Types
 Unauthorized Finding Types

22. 22例：Backdoor:EC2/C&CActivity.B!DNS
EC2 instance is querying a domain name that is associated with a known command and
control server.
（EC2インスタンスがC&Cサーバーに関連付けられているドメイン名のクエリを実行している）

23. 23例：Backdoor:EC2/C&CActivity.B!DNS

24. 24新たに発生するセキュリティ上の脅威にどのように対応していますか？
□ 最新の組織、法律、コンプライアンスの要件を調査して、求められる要件が最新であることを
保っている
□ AWSおよび業界についての最新セキュリティベストプラクティスを確認している
□ 最新のセキュリティ脅威(新たな攻撃手法など)を把握している
□ 新しいセキュリティサービス(AWSやAPN)や機能を定期的に評価している
□ 脅威モデルを利用してリスクを定義して、あらかじめ対応時の優先順位を決定している
□ 新しいセキュリティサービスや機能を実装している

25. 25CapitalOneの事例
SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた
https://piyolog.hatenadiary.jp/entry/2019/08/06/062154

26. 26Instance Profile / Instance Metadata（再掲）
Instance Profileは、インスタンスにIAM Roleの一時的な認証情報を渡すために利用
一時的な認証情報はInstance Metadata経由で取得
AWS CLI / SDKをインスタンス上で利用する場合、認証情報の取得を意識する必要はない
$ 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"
}
Retrieving Security Credentials from Instance Metadata
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials

27. 27例：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 アドレスから使用
されています。）
＝ 「侵害されている可能性がある」

28. 28例：UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration

29. 29インフラストラクチャの保護
SEC 6: How do you protect your networks?
（ネットワークをどのように保護していますか？）
SEC 7: How do you protect your compute resources?
（コンピューティングリソースをどのように保護していますか？）

30. 30ネットワークをどのように保護していますか？
□ ネットワークアクセス要件を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義して
いる
□ ネットワークアクセスは必要最小限のみ許可している
□ ネットワーク設定について構成管理ツールなどを活用して自動化している
□ ネットワーク保護を自動化している(脅威インテリジェンスと異常検出)
□ アプリケーションレベルの検査と保護を実施している(WAFの活用など)
□ すべてのレイヤーでトラフィックを制御している(SecurityGroup, NACLとSubnetなど)

31. 31CloudFormationによるプロビジョニング
CloudFormationを利用したAWSリソースのコード化
• プロビジョニング前にレビュー可能
• Gutリポジトリなどで変更管理も容易に実現可能
InstanceSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Allow http to client host
VpcId:
Ref: myVPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
SecurityGroupEgress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0

32. 32CloudFormationテンプレートに対するセキュリティリスクの評価
OSS
• cfn-nag : https://github.com/stelligent/cfn_nag
Commercial
• Dome9 (preview) :
https://sc1.checkpoint.com/documents/CloudGuard_Dome9/Documentation/Complia
nce-and-Governance/CFTAssessment.html

33. 33プロビジョニング済のリソースに対するセキュリティリスクの評価
Config Rules/Security Hubによるコンプライアンスチェック
• Config Rules Managed Rule
• https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/managed-rules-
by-aws-config.html
• Security Hub Compliance Standards : CIS AWS Foundations
• https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-
standards.html

34. 34ENSURE NO SECURITY GROUPS ALLOW INGRESS FROM 0.0.0.0/0 TO SSH (TCP:22)
ENSURE NO SECURITY GROUPS ALLOW INGRESS FROM 0.0.0.0/0 TO SSH (TCP:22)
https://gsl.dome9.com/D9.AWS.NET.01.html

35. 35コンピューティングリソースをどのように保護していますか？
□ コンピュートリソースの保護要件を適切(法令、ガイドライン、社内ルールなどに合わせて)に定
義している
□ コード、インフラそれぞれの脆弱性を頻繁にスキャンして修正している
□ 構成管理ツールなどを活用して構成管理を自動化している(人為的エラーのリスク削減)
□ コンピューティング保護を自動化している(仮想パッチの使用など)
□ 攻撃対象となる箇所を減らしている(ハードニング、コンテナやサーバレスの活用)
□ セキュリティメンテナンス作業軽減のためにマネージドサービスを活用する(RDS、Lambda、
ECSなど)

36. 36定期的な脆弱性スキャン（Application）
【F-Secure Radar API + CodePipeline】脆弱性診断の実行から結果取得、判定まで全自動でやってみた
https://dev.classmethod.jp/cloud/aws/all-auto-vulscan-with-pipeline/

37. 37定期的な脆弱性スキャン（OS / Middleware）
【資料公開】PCI DSSの認証取得を目指す方へ！AWSの利用を前提としたパッチ管理について考えるクローズドな勉強会をやりました
https://dev.classmethod.jp/cloud/aws/pci-dss-study-20190603-ssm-patch-manager/

38. 38データの保護
SEC 8: How do you classify your data?
（データをどのように分類していますか？）
SEC 9: How do you protect your data at rest?
（保存しているデータをどのように保護していますか？）
SEC 10: How do you protect your data in transit?
（転送しているデータをどのように保護していますか？）

39. 39データをどのように分類していますか？
□ データ分類を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義している
□ データ分類ルールに応じたデータ保護を定義している
□ データ識別を実装している(S3バケットやオブジェクトへのタグ付など)
□ データ分類と識別を自動化している(人為的エラーのリスク削減)
□ データのタイプを特定している(各種要件を満たすためのコントロール実装のため)

40. 40Macie
Macieでできること
• データの検出と分類
• データに対するアクティビティの監視
• データの可視化（分類、アクティビティ）
• データに対する不審なアクティビティ発生時にアラート
分類手法
• コンテンツタイプ / ファイル拡張子 / テーマ / 正規表現 / 個人情報(PII) / SVMベースの分類

41. 41例：個人識別情報、クレジットカード番号を検出

42. 42保存しているデータをどのように保護していますか？
□ 保存データについて管理と保護を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義
している
□ 安全な鍵管理の実装をしている(KMSの活用、データ保護要件に合わせた異なる鍵の使用)
□ 保存データの暗号化を強制している
□ 保存データへのアクセス制御を強制している(最小権限の原則、自動化など)
□ 人々をデータから遠ざけるための仕組みを実装している(直接アクセスを避けるため、ダッシュ
ホードや管理ツールを用意するなど)

43. 43AWSサービスのKMS対応
AWS KMS
• 暗号鍵の作成、管理、運用のためのサービス
KMSをサポートするAWSサービス
• S3、EBS、RDS、RedShift などでの Server-side Encryption
• https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/service-
integration.html
Client-side Encryption
• ユーザーアプリケーションでの暗号化でKMSの暗号鍵を利用することも可能

44. 44Envelope Encryption
Envelope Encryption
https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/how-it-works.html#envelope-encryption

45. 45転送しているデータをどのように保護していますか？
□ 転送データについて管理と保護を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義
している
□ 安全な鍵や証明書管理の実装をしている(AWS Certificate Managerの活用など)
□ 転送データの暗号化を強制している
□ データ漏洩を自動検出する仕組みを実装している(未知のホストへのデータ転送など)
□ 転送データの改竄や紛失を防止するためネットワーク通信を認証している(TLSやIPSecの利用)

46. 46インシデントレスポンス
SEC 11: How do you respond to an incident?
（セキュリティインシデントにどのように対応していますか？）

47. 47セキュリティインシデントにどのように対応していますか？
□ インシデント対応のための社内外の人員を把握している
□ インシデント対応のためのツールを準備している
□ インシデント対応計画が事前に策定されている(社内および社外への連絡やエスカレーション方法
も含む)
□ インシデント発生時に被害を封じ込めるための自動化している
□ 外部の専門家も含めたフォレンジック調査を行っている
□ インシデント対応に必要なアクセス権が事前にセキュリティ担当者に設定されている
□ インシデント対応に必要なツールが事前にセキュリティ担当者に配布されている
□ ゲームデー(定期的なインシデント対応訓練)を実施して、対応や計画を改善している

48. 48Config RulesによるRemediation（修復）
Config RulesでNon-compliantなリソースを検出したら修正のためのアクションを実行できる
アクションはSystems ManagerのAutomation用のDocumentで定義
例：
• Config Rulesのマネージドルール “cloudtrail-enabled” でCloudTrailが無効になっていることを検出
• Remediation Actionとして、Systems Manager Automation Document “AWS-EnableCloudTrail” を
実行
cloudtrail-enabled
https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/cloudtrail-enabled.html
AWS-EnableCloudTrail
https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-enablecloudtrail.html

49. 49AWS-EnableCloudTrail (Systems Manager Automation Document)

50. 50EC2 Auto Clean Room Forensics
EC2 Auto Clean Room Forensics
https://github.com/awslabs/aws-security-automation/tree/master/EC2%20Auto%20Clean%20Room%20Forensics

51. 51
まとめ

52. 52設計原則（再掲）
• 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（セキュリティイベントに備える）

53. 53まとめ
設計と実装だけでなく、要件定義と運用・体制も重要
時間と共に変わる「脅威」「最適な設計」（設計の定期的な見直しが重要）
規模や求められる正確性によっては自動化することも重要

54. 54