Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

671 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. AWS Well-Architected Tool 活用術セミナー セキュリティ編 2019/09/05 Nobuhiro Nakayama 1
  2. 2. 2Agenda • 設計原則 • ベストプラクティス • まとめ
  3. 3. 3 設計原則
  4. 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. 5 ベストプラクティス
  6. 6. 6ベストプラクティス • Identity and Access Management(認証・認可) • Detective Controls(発見的統制) • Infrastructure Protection(インフラストラクチャの保護) • Data Protection(データの保護) • Incident Response(インシデントレスポンス)
  7. 7. 7 難しめの質問事項を中心に解説
  8. 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. 9認証情報と認証をどのように管理していますか? □ アクセス要件を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義している □ ルートユーザにMFA(多要素認証)を設定、アクセスキーを削除し、最小限の利用に留めている □ MFA(多要素認証)を強制している □ ツールなどを用いてアクセス制御を自動化している(Organizations SCP など) □ IDプロバイダもしくはディレクトリサービスを使用している □ 適切なパスワード要件を強制している □ 認証情報を定期的にローテーションしている(退職者などの不正利用防止) □ 定期的に認証情報の監査を行っている(アクセス要件、MFA、ローテーションなどの確認)
  10. 10. 10人によるアクセスをどのように制御していますか? □ 人為的なアクセス要件を適切に定義している(不要な特権アクセスのリスクを軽減) □ 最小限の権限を付与している □ 各個人に固有の認証情報を割り当てている □ ユーザーのライフサイクルに基づいて認証情報を管理している(退職者の情報削除など) □ 認証情報管理を自動化している □ ロールまたはフェデレーションを介してアクセスしている
  11. 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. 12. 12Automated IAM User Cleanup
  13. 13. 13プログラムによるアクセスをどのように制御していますか? □ プログラムにアクセス要件を適切に定義している(不要な権限によるアクセスのリスクを軽減) □ 最小限の権限を付与している □ 認証情報管理を自動化している(動的認証の管理やレポートなど) □ 各コンポーネントに固有の認証情報を割り当てている(LambdaとEC2でIAMロールを分けるな ど) □ ロールまたはフェデレーションを介してアクセスしている □ 動的認証を実装している(認証情報を動的に取得し、自動的にローテートされる)
  14. 14. 14STS(Security Token Service) による一時認証情報の発行 STS(Security Token Service)とは • 一時的な認証情報をリクエストするための サービス • フェデレーションを実現するために利用 • マネージメントコンソール上でスイッチ ロールするためにも利用 STS API Reference https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html
  15. 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. 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. 17発見的統制 SEC 4: How do you detect and investigate security events? (セキュリティイベントの検知と調査をどのように行っていますか?) SEC 5: How do you defend against emerging security threats? (新たに発生するセキュリティ上の脅威にどのように対応していますか?)
  18. 18. 18セキュリティイベントの検知と調査をどのように実施していますか? □ ログの要件を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義している □ メトリクスの要件を適切に定義している □ 通知の要件を適切に定義している □ アプリケーションログやAWSサービスのログなどワークロード全体のログを取得している □ ログを一元的に分析している □ 重要なメトリクスやイベントの監視と通知を行っている □ インシデント対応のために、エスカレーションパスも含めた調査プロセスが確立している
  19. 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. 20ログの集約と分析 Centralized Logging https://aws.amazon.com/solutions/centralized-logging/
  21. 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. 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. 23例:Backdoor:EC2/C&CActivity.B!DNS
  24. 24. 24新たに発生するセキュリティ上の脅威にどのように対応していますか? □ 最新の組織、法律、コンプライアンスの要件を調査して、求められる要件が最新であることを 保っている □ AWSおよび業界についての最新セキュリティベストプラクティスを確認している □ 最新のセキュリティ脅威(新たな攻撃手法など)を把握している □ 新しいセキュリティサービス(AWSやAPN)や機能を定期的に評価している □ 脅威モデルを利用してリスクを定義して、あらかじめ対応時の優先順位を決定している □ 新しいセキュリティサービスや機能を実装している
  25. 25. 25CapitalOneの事例 SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた https://piyolog.hatenadiary.jp/entry/2019/08/06/062154
  26. 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. 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. 28例:UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
  29. 29. 29インフラストラクチャの保護 SEC 6: How do you protect your networks? (ネットワークをどのように保護していますか?) SEC 7: How do you protect your compute resources? (コンピューティングリソースをどのように保護していますか?)
  30. 30. 30ネットワークをどのように保護していますか? □ ネットワークアクセス要件を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義して いる □ ネットワークアクセスは必要最小限のみ許可している □ ネットワーク設定について構成管理ツールなどを活用して自動化している □ ネットワーク保護を自動化している(脅威インテリジェンスと異常検出) □ アプリケーションレベルの検査と保護を実施している(WAFの活用など) □ すべてのレイヤーでトラフィックを制御している(SecurityGroup, NACLとSubnetなど)
  31. 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. 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. 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. 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. 35コンピューティングリソースをどのように保護していますか? □ コンピュートリソースの保護要件を適切(法令、ガイドライン、社内ルールなどに合わせて)に定 義している □ コード、インフラそれぞれの脆弱性を頻繁にスキャンして修正している □ 構成管理ツールなどを活用して構成管理を自動化している(人為的エラーのリスク削減) □ コンピューティング保護を自動化している(仮想パッチの使用など) □ 攻撃対象となる箇所を減らしている(ハードニング、コンテナやサーバレスの活用) □ セキュリティメンテナンス作業軽減のためにマネージドサービスを活用する(RDS、Lambda、 ECSなど)
  36. 36. 36定期的な脆弱性スキャン(Application) 【F-Secure Radar API + CodePipeline】脆弱性診断の実行から結果取得、判定まで全自動でやってみた https://dev.classmethod.jp/cloud/aws/all-auto-vulscan-with-pipeline/
  37. 37. 37定期的な脆弱性スキャン(OS / Middleware) 【資料公開】PCI DSSの認証取得を目指す方へ!AWSの利用を前提としたパッチ管理について考えるクローズドな勉強会をやりました https://dev.classmethod.jp/cloud/aws/pci-dss-study-20190603-ssm-patch-manager/
  38. 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. 39データをどのように分類していますか? □ データ分類を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義している □ データ分類ルールに応じたデータ保護を定義している □ データ識別を実装している(S3バケットやオブジェクトへのタグ付など) □ データ分類と識別を自動化している(人為的エラーのリスク削減) □ データのタイプを特定している(各種要件を満たすためのコントロール実装のため)
  40. 40. 40Macie Macieでできること • データの検出と分類 • データに対するアクティビティの監視 • データの可視化(分類、アクティビティ) • データに対する不審なアクティビティ発生時にアラート 分類手法 • コンテンツタイプ / ファイル拡張子 / テーマ / 正規表現 / 個人情報(PII) / SVMベースの分類
  41. 41. 41例:個人識別情報、クレジットカード番号を検出
  42. 42. 42保存しているデータをどのように保護していますか? □ 保存データについて管理と保護を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義 している □ 安全な鍵管理の実装をしている(KMSの活用、データ保護要件に合わせた異なる鍵の使用) □ 保存データの暗号化を強制している □ 保存データへのアクセス制御を強制している(最小権限の原則、自動化など) □ 人々をデータから遠ざけるための仕組みを実装している(直接アクセスを避けるため、ダッシュ ホードや管理ツールを用意するなど)
  43. 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. 44. 44Envelope Encryption Envelope Encryption https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/how-it-works.html#envelope-encryption
  45. 45. 45転送しているデータをどのように保護していますか? □ 転送データについて管理と保護を適切(法令、ガイドライン、社内ルールなどに合わせて)に定義 している □ 安全な鍵や証明書管理の実装をしている(AWS Certificate Managerの活用など) □ 転送データの暗号化を強制している □ データ漏洩を自動検出する仕組みを実装している(未知のホストへのデータ転送など) □ 転送データの改竄や紛失を防止するためネットワーク通信を認証している(TLSやIPSecの利用)
  46. 46. 46インシデントレスポンス SEC 11: How do you respond to an incident? (セキュリティインシデントにどのように対応していますか?)
  47. 47. 47セキュリティインシデントにどのように対応していますか? □ インシデント対応のための社内外の人員を把握している □ インシデント対応のためのツールを準備している □ インシデント対応計画が事前に策定されている(社内および社外への連絡やエスカレーション方法 も含む) □ インシデント発生時に被害を封じ込めるための自動化している □ 外部の専門家も含めたフォレンジック調査を行っている □ インシデント対応に必要なアクセス権が事前にセキュリティ担当者に設定されている □ インシデント対応に必要なツールが事前にセキュリティ担当者に配布されている □ ゲームデー(定期的なインシデント対応訓練)を実施して、対応や計画を改善している
  48. 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. 49. 49AWS-EnableCloudTrail (Systems Manager Automation Document)
  50. 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. 51 まとめ
  52. 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. 53まとめ 設計と実装だけでなく、要件定義と運用・体制も重要 時間と共に変わる「脅威」「最適な設計」(設計の定期的な見直しが重要) 規模や求められる正確性によっては自動化することも重要
  54. 54. 54

×