Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで]

 [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで]

解説と登壇時の動画を載せたブログは以下です。こちらを見てください。シェアもブログの方をお願いします。
https://dev.classmethod.jp/articles/aws-security-all-in-one-2021/
イベントページはこちら。
DevelopersIO 2021 Decade
https://classmethod.jp/m/devio-2021-decade/

cm-usuda-keisuke

October 06, 2021
Tweet

More Decks by cm-usuda-keisuke

Other Decks in Technology

Transcript

  1. 17 守りたいもの(⼀部のざっくりした視点) • データ • 機密情報 • 顧客データ • 個⼈情報

    • クレジットカード • コンテンツ • 利⽤者 • 個⼈情報 • アップしたコンテンツ • 会社 • 業務システム • 会社⾃体 • 企業イメージ • 従業員 • お⾦
  2. 19 守るものを把握する • どこにあるのか • 誰が責任者か • 誰が管理しているのか • 誰がアクセスできるのか

    • 今すぐに状態がわかるか すべて把握できていないと守れない 資産の洗い出し・特定して管理する まず洗い出し
  3. 24 設計にセキュリティを リスクがわかれば設計に反映できる • アクセス権限の洗い出し • 許可払い出しフローの管理 • 不要なサーバーポートの確認 •

    ソフトウェアの脆弱性管理 • ログの収集 • 送信元IPの集計 • 不審なIPのアラート やること と優先順 位が⾒え てくるぞ
  4. 26 セキュリティは誰の責任︖ • セキュリティ担当者だけではない • 開発者 • 運⽤者 • 監査⼈

    • 経営者 • などなど • つまり全員セキュリティ担当 • 必要な⼈が必要な範囲⾏う(責任範囲) 関係ない⼈は いないぞ
  5. 28 セキュリティの原則 • 最⼩権限 • 多層防御 • 識別・認証・認可 • システムの堅牢化

    • フェールセーフ • シンプルにする • 職務の分離 • Design for Failure • ⼈は間違える • などなど
  6. 29 知らないと守れない • セキュリティの原理原則 • NIST CSF • 攻撃者の気持ち •

    AWSの特徴 • 便利なセキュリティ機能 • AWSの情報源 • 各AWSサービスUser Guideの「セキュリティ」ページ • JAWS-UG • ググる 常にキャッチ アップだ
  7. 37 AWSの脅威 • 誤った情報の公開・アクセス許可 • AWSはローカルPCの環境や社内の検証環境ではない • 簡単に外部に公開して迅速に展開できる基盤 • 権限不備で情報漏えいが起きたり

    • 不正な攻撃者がアカウントを乗っ取ることも • 資⾦の浪費 • 従量課⾦で安く使い始められるけど、適切に管理しない と請求がすごいことに
  8. 41 最初にやること抜粋 • IAMユーザーを作ってルートユーザーをMFAで封印 • 必要なサービス有効化 • CloudTrail • Config

    • GuardDuty • Security Hub • IAM Access Analyzer • Detective • Well-Architectedフレームワーク読む
  9. 42 IAM • Identity and Access Management • AWSにおけるアクセス制御の基本であり極意 •

    セキュリティの原則に従い利⽤ • 個別のIDを発⾏する • 最⼩権限 • MFA設定 • アクセスキーの利⽤は注意 • すべてのAWS利⽤者が理解する必要がある
  10. 47 Config • 各種AWSリソースの変更を記録・管理する • 時系列に変更を辿れる • セキュリティグループがいつ作られたか • いつどのように変更されたか

    • 関連性を辿れる • どのEC2と紐付いているか • どのVPCと紐付いているか • 問題ある設定を是正する
  11. 59 ⼀般的なセキュアWeb環境 • 3層アーキテクチャ • EC2はプライベート • SSM Session Managerでア

    クセス(SSHしない、これ最 強。) • CloudFront + S3 + WAF • マルチAZ • Auto Scaling
  12. 62 コンピューティング(EC2) • EC2は直接パブリックに置かない(攻撃経路を無くす) • OS/ミドルのパッチは常に最新に(脆弱性管理) • SSHも可能な限りSession Managerを使う •

    最低限のポートだけ開ける • ログを外部出⼒する(CloudWatchやS3) • マルウェア対策する • IAM Roleは最⼩権限に(SSRF対策) • 可能ならIMDSv2を利⽤する
  13. 64 コンピューティング(コンテナ) • ⾃前でDockerなどを動かさずにECS/EKSを利⽤す る(管理部分の委任) • AWSが管理している基盤のほうがセキュア • Fargateを利⽤する(管理部分の委任) •

    信頼できるリポジトリを利⽤ • イメージをスキャンする(脆弱性管理) • ログを外部出⼒する(awslogs/FireLens) • NIST SP800-190もチェック
  14. 66 コンピューティング(Lambda) • 認証・認可されていないリクエストを受け付けない (アクセス制御) • 外部からのリクエストを処理する場合はAPI Gatewayをフロントに⼊れる • 強い権限のIAM

    Roleをアタッチしない(最⼩権限) • 脆弱性のあるパッケージを利⽤しない(脆弱性管理) • 実⾏数のクォータをモニタリングする(可⽤性)
  15. 67 ネットワーク • 必要な単位でVPCを分割する(相乗りしない) • Security Groupで詳細なアクセス制御する • 最低限のポート •

    最低限の送信元 • Security Group ID指定での制御(無駄にIP指定しない) • NACLでポリシー的なアクセス制御する • VPC EndpointによるセキュアなAWSアクセス
  16. 68 データベース • RDS / DynamoDBなどマネージドなサービスを利 ⽤する(責任範囲) • マルチAZ /

    リードレプリカによる冗⻑化 • バックアップによる復旧可能性 • TLSによる通信経路の暗号化 • IAMによる管理アクセスの制御 • ユーザー毎データアクセス権限の最⼩化
  17. 69 ストレージ(S3) • S3のアクセス制御機能の理解 • まずはパブリックアクセスブロック • バケットポリシー / ACL

    • バージョニング • オブジェクトロック(WORM) • クロスリージョンレプリケーション • アクセスポイント(アクセス制御の分割) • セキュリティベストプラクティス読む • https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/security-best-practices.html • ユーザーアップロードがあるならスキャン
  18. 70 合わせて読みたい Cloud One File Storage Securityは サーバレスにS3をマル ウェアスキャンできる 素晴らしい仕組み

    https://dev.classmethod.jp/a rticles/trendmicro- introducing-security-for- cloud-object-storage/
  19. 71 OS/ミドル • とにかく脆弱性管理 • 脆弱性診断だけではない • AWSならSSMインベントリ + Inspector

    + SSM パッチマネージャから始める • より快適なのはFutureVulsなど1つの基盤で⼀連の 脆弱性管理ができる仕組み
  20. 76 アプリ(続き) • といっても⼤変なのでAWSの便利な機能を利⽤する • 認証基盤としてCognitoが利⽤できると⾃前で実装しなく て済む • Advanced Securityで認証強化

    • アダプティブ認証(通常と違うログイン対策) • 侵害された認証情報(漏洩したパスワード対策) • AWS WAFを利⽤してフロントで攻撃を⽌められる • 認証情報は埋め込まないでSSMパラメータストアや Secrets Managerに保管する • ⾃動化された安全な仕組みでリリースする
  21. 79 モニタリング/ログ • 現在の状態・過去の状態を確認することは必須 • 未来の状態も予測できる • CloudWatchメトリクスから必要な情報を得る • コンピューティングリソースの状態

    • サービス・ビジネスメトリクス • ログから詳細なインサイトを得る • エラーなどを検知する • 最新のCloudWatch機能を活⽤する • 合成監視とか
  22. 91 AWSのセキュリティ維持 • AWS Config RulesによりAWSの状態を確認し、定 義した状態から違反したらアラートを出せる • アラートから⾃動修復も可能 •

    Security HubはConfig Rulesを利⽤したセキュリ ティチェックが可能 • 詳細なアクセス制御の維持にはIAM Access AnalyzerやPermissions Boundaryを利⽤する
  23. 96 Config Rulesのチェック項⽬ • ルールは2種類ある • AWSマネージドルール: ⽤意されている • カスタムルール:

    ⾃前のLambdaでチェックできる • マネージドルールの例 • SecurityGroupでSSHが0.0.0.0/0で許可されていないか • CloudTrailが有効か • S3バケットが暗号化されているか • RDSのバックアップが有効か • などなど100種類以上 • https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/managed-rules-by-aws-config.html
  24. 99 Config Rulesを活⽤した仕組み • Config Rulesは様々なチェックが可能 • これを応⽤するAWSサービスがある • Conformance

    Packs • CloudFormationのようにRulesをYAML/JSONで定義してデプ ロイできる • サンプルテンプレートが50個以上ある • Security Hub • 3種類のルールセットがある • ⾃動展開できる • 個別の検知抑制が可能
  25. 102 セキュリティチェック⽅法 • Security Hubはセキュリティチェック運⽤の理想形 • 直感的なスコア表⽰ • 無効化・例外の設定管理 •

    AWSが最新のベストプラクティスを適⽤ • 「AWS の基本的なセキュリティのベストプラクティスコント ロール(AWS Foundational Security Best Practices)」の ルールが優秀 • 現状30リソースタイプ・121種類のチェック • 更新頻度が⾼い(リリースから約1年半で13回更新) • ⾃動修復ソリューション • マルチアカウントの集約
  26. 105 対応リソースタイプ • ACM • Apigateway • AutoScaling • CloudFront

    • CloudTrail • CodeBuild • Config • DMS • DynamoDB • EC2 • ECS • EFS • ElasticBeanstalk • ELB • ELBv2 • EMR • ES • GuardDuty • IAM • KMS • Lambda • RDS • Redshift • S3 • SageMaker • SecretsManager • SNS • SQS • SSM • WAF
  27. 111 Security Hub以外を使う場合 • Security Hubも完璧ではない • Conformance Packsを利⽤する場合 •

    サンプルテンプレートを活⽤したい • ガリガリルールセットをカスタマイズしたい • ⾃動修復も独⾃で設定したい • カスタムルール(Lambda)を利⽤したい
  28. 121 Permissions Boundaryとは • IAMエンティティに追加で付 与できる • 元々のポリシー(アイデンティ ティベースポリシー)に加えて Permissions

    Boundaryで も許可されている権限しか実 ⾏できない • 作成するIAMにBoundaryを つけることを強要できる
  29. 128 AWSのインシデント検知と対応 • Amazon GuardDuty(マネージドな脅威検知サービ ス)でいろんな脅威を検知 • EC2でコインマイニング • IAM不正利⽤

    • S3への不審なアクセス • などなど • Amazon Detectiveで⾃動的にログを関連付けして 簡単に調査 • ユーザーガイドに対処⽅法がある
  30. 137 Amazon GuardDutyとは • 脅威検知サービス • CloudTrail / VPC Flow

    Logs / DNS Logsをバッ クグラウンドで⾃動収集(利⽤者の⼿間なし) • ポチッと有効化するだけ • IAM / EC2 / S3に関するインシデントを検知 • 脅威インテリジェンスと連携 • 機械学習による異常識別
  31. 138 GuardDutyの検知内容(ほんの⼀部) • IAMタイプ • 不正ログイン • 漏洩したクレデンシャル利⽤ • CloudTrail無効化

    • EC2タイプ • コインマイニング • C&Cサーバー接続 • SSHブルートフォース(受信 or 送信) • S3タイプ • バケット公開 • Torアクセス
  32. 140 初動対応計画 • 検知結果毎ざっくり3種類準備しておく • IAMタイプ • 認証情報を無効化する • EC2タイプ

    • EC2を隔離、保全、調査する • 調査は得意な会社に依頼できる準備でもいい • S3タイプ • アクセス権限を絞る
  33. 146 その他の計画 • エスカレーションフローなども決めておこう • 誰がいつまでにどこまで判断するか • 必要なログは収集しておこう • インシデント検知のアラートと⼀緒に⽬につくよう

    に対応することを出そう • いざという時は対応漏れが起きやすいのでチェック リストなどで簡単に実⾏できるようにしよう • 予⾏練習たくさんやろう
  34. 156 しかしログの調査は⼤変 • ノイズが多い • ちょうどいいログクエリを探すのに⼀苦労 • 関連性を⾒出しづらい • クエリではなく、あらかた絞った状態でエクセルで検索

    を駆使したり⽬grepしてがんばる • 動的な範囲の集計やりづらい • この時間範囲のこのユーザーの実⾏API数とか、ぐりぐり 動かしながらやりたい • 異常値を⾒つけにくい • どの観点で分析したらいいかわからん
  35. 159 Amazon Detectiveとは • インシデント調査のサービス • VPC Flow Logs /

    CloudTrail / GuardDuty Findingsを⾃動で取り込む • わかりやすいグラフやマップで視覚化
  36. 168 調査の進め⽅ • Detectiveを使うことで調査が⼤幅に捗る • 何が起きているかの全体像把握 • 関連リソース把握 • 起因になっている事象を辿る

    • しかし最終的には⾃分でログを⾒る場合もある • ログを⾒る仕組みを⽤意するのも⽅法の1つ
  37. 170 SIEM on Amazon OpenSearch Service CloudTrailの可視化 こんな感じ ログイン失敗とか ルートのログインと

    かチェックしたい項 ⽬が最初からダッ シュボードに搭載さ れている
  38. 175 合わせて読みたい AWS上のインシデントをわかりやす いフロー図にして可視化できる Radware Cloud Native Protectorを使って攻撃された痕跡 を調査してみた https://dev.classmethod.jp/articles/getting-

    start-radware-cloud-native-protector/ AWSでコインマイニングされた原 因をRadware CNPのフロー図で わかりやすく調査してみた https://dev.classmethod.jp/articles/investig ate-coin-mining-with-radware-cnp/
  39. 185 SCPの例 • SCPの例 • 特定リージョン使⽤禁⽌ • CloudTrail無効化禁⽌ • GuardDuty無効化禁⽌

    • S3バケット公開禁⽌ • タグのないリソース作成禁⽌ • https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/ orgs_manage_policies_scps_examples.html • 開発環境 / 本番環境 / 共⽤環境などで使い分ける
  40. 188 AWS Organizations連携 • 様々なAWSサービスと連携して簡単に全体管理でき る • AWS SSO •

    CloudFormation StackSets • GuardDuty • Security Hub • Systems Manager • CloudTrail • Config • などなど
  41. 197 Control Towerの役割 • ID管理 • AWS SSOと連携した認証認可の集約 • ガードレール

    • SCPやConfig Rulesにより違反を防⽌・検知 • ベースライン展開 • CloudTrailやConfigなど⼀律で展開 • ログ管理・監視 • Log Archiveアカウントにログ集約 • Auditアカウントにアラート集約
  42. 202 CCoEによるクラウド活⽤最適化 • CCoE: Cloud Center of Excellence • クラウド推進の組織

    • クラウド利⽤のノウハウを持つ・蓄える・提供する • 企業により定義や構成はさまざま • バーチャル組織で部⾨横断 • 情シスから派⽣ • DX推進チーム • クラウドのスピードに合わせて変わっていく