「AWSアカウントの現状を把握できてますか？それ、Dome9でよく見えますよ。」 Developers.IO 2019 Security
•
0 gefällt mir•2,111 views
「AWSアカウントの現状を把握できてますか？それ、Dome9でよく見えますよ。」 Developers.IO 2019 Security
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 「AWSアカウントの現状を把握できてますか？それ、Dome9でよく見えますよ。」 Developers.IO 2019 Security
Ähnlich wie 「AWSアカウントの現状を把握できてますか？それ、Dome9でよく見えますよ。」 Developers.IO 2019 Security (20)
Mehr von Nobuhiro Nakayama
Mehr von Nobuhiro Nakayama (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
「AWSアカウントの現状を把握できてますか？それ、Dome9でよく見えますよ。」 Developers.IO 2019 Security
- 2. 2後半のパートでお話すること Dome9の使いどころ / ユースケース Dome9のデモ まとめ
- 3. 3主な機能（改めて） Compliance & Governance • セキュリティフレームワークに基づくRule SetでAWS環境を評価 • 独自のRule Setを定義することも可能 Network Security • Security Groupによるアクセス許可を可視化 • IPアドレス／ネットワークアドレスを集中管理 （マルチアカウントにも対応） IAM Safety • IAM Userに対して時限的に特権を付与
- 6. 6ユースケース Dome9 • 現状把握 • どこからどこに通信可能なのか？ • セキュリティの観点で不適切な設定が存在しないか？ • 一時的なアクセス許可 / 権限の付与 • 管理業務を委託しているベンダーに対して一時的にアクセスを許可 / Security Groupの変更を厳密に統制 • 管理業務を委託しているベンダーに対して一時的に操作権限を付与 • 複数のAWSアカウントの管理 • IPアドレスの集中管理
- 8. 8現状を把握できていますか？ 例えば・・・ • 単一のアカウントで複数のワークロードが稼働／連携 （設計自体が複雑） • 運用 / 保守で必要なアクセス許可を都度設定 （そして、設定を戻し忘れている・・・） • アクセス許可を与える権限を現場に委任している （その後、どうなっているか分からない） 定期的な棚卸し／見直しがつらい！
- 9. 9これが・・・ 2つのSecurity Groupをアタッチ • 任意のIPアドレスからHTTP/HTTPSでのアクセスを許可 • 特定のIPアドレスからSSHでのアクセスを許可 1つのSecurity Groupをアタッチ • 前段のEC2インスタンスに割り当てたSecurity Group（1つ目）からTCP/3306でのアクセスを許可
- 10. 10こう見えます
- 12. 12これは・・・ Web Application Proxy on AWS https://aws.amazon.com/quickstart/architecture/wap-adfs/
- 13. 13こうなる
- 14. 14データフローがよくわからん・・・ なぜか • Security GroupのSourceにSecurity Groupではなく、 ネットワークアドレスを利用している • データフローを確認したい / そもそも厳密にアクセス制御したい場合には SourceにSecurity Groupを利用しましょう • 役割が異なるインスタンスに同じSecurity Groupを併用してしまった場 合にも意図したような可視化はできない
- 16. 16そもそも、何をチェックすればいいのか？ 様々なセキュリティフレームワークが公開されている • Dome9は以下のフレームワークに基づくルールセットを提供 • CIS, NIST 800-53, PCI-DSS 3.2, HIPAA, GDPR, ISO27001, SOC2, NIST CSF v1.1, CSA CCM v3.0.1, Serverless Security • これらの枠組みでリスクを洗い出すことが可能 • リスクの大きさはケースバイケースなので、都度評価が必要 Compliance Engine Bundles & Rules https://helpcenter.dome9.com/hc/en-us/articles/360003963114-Compliance-Engine-Bundles-Rules
- 17. 17PCI DSSの場合 要件1.2.1 • “着信および発信トラフィックを、カード会員データ環境に必要な トラフィックにし、それ以外のすべてのトラフィックを特定的に拒 否する” Payment Card Industry（PCI）データセキュリティ基準 要件とセキュリティ評価手順 バージョン 3.2.1 2018年5月 https://ja.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf
- 19. 19Dome9で提供される評価ルール PCI-DSS 3.2 に基づいたルールセットを提供 • 要件1.2.1に関連するルールは以下の7つ • Ensure S3 buckets are not publicly accessible • Ensure no security groups allow ingress from 0.0.0.0/0 to ALL ports and protocols • Ensure no security groups allow ingress from 0.0.0.0/0 to RDP (TCP:3389) • Ensure no security groups allow ingress from 0.0.0.0/0 to SSH (TCP:22) • Ensure the default security group restricts all traffic • Security Groups - with admin ports too exposed to the public internet • Restrict outbound traffic to that which is necessary, and specifically deny all other traffic
- 20. 20権限の付与しすぎも検出することが可能 PCI-DSS 3.2 に基づいたルールセットでも完全なアクセス権 を与えるポリシーの存在を検知できる • Ensure IAM policies that allow full "*:*" administrative privileges are not created • 要件 7.1, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.2 に対応 • 要件7では特権ID付与の最小化が求められる
- 21. 21特権への昇格リスク 例）SSRF(Server Side Request Forgery)を利用した認証 情報の摂取 • EC2インスタンスのインスタンスメタデータから一時認証情報を取 得できる • 権限はインスタンスプロファイルに割り当てたポリシーで定義 • 脆弱性があるとSSRFを利用して認証情報を摂取される可能性があ る（根本的な対策はアプリケーションで実施すべき） • インスタンスに付与する権限を最小化することで 特権昇格のリスクを緩和することはできる
- 24. 24リスクを是正はしたものの・・・ 運用次第では新たなリスクの発生も考えられる • 「一時的に」アクセスを許可したが、その許可を削除し忘れる • 例）運用の委託先などからのアクセスが許可されたまま
- 25. 25Dynamic Access 一時的にネットワークアクセスを許可 • 指定した時間を経過したらDome9が許可を削除してくれる • 設定の流れ（全てDome9のコンソール上から実行） • SecurityGroupの保護モードを有効化 • Dynamic Access用のルールを定義 • この時点ではSecurity Groupには何も設定されない • 一時的なアクセスを許可
- 26. 26保護モードを有効化
- 28. 28アクセスを許可／招待
- 30. 30リンクをクリック
- 34. 34Tamper Protection Dome9でSecurity Groupを集中管理 • AWSのマネージメントコンソールからの変更は Dome9によって強制ロールバック • リージョン単位／Security Group単位で保護することが可能 • Security Groupの変更はDome9のコンソールで実施
- 35. 35検知 変更を検知
- 37. 37ID / 権限の管理、できてますか？ IAMの管理権限を持つということ＝新たな管理者を生み出せる • 運用負担を分散するために権限を持つ担当者を複数任命すること はよくある • むしろ、1人しか管理権限を持っていないという状態はハイリスク • しかし、その管理者が悪意を持ったら？ • IAM以外のサービスでも、 変更／削除の権限があると破壊的な影響を及ぼすことが可能 • 定型的なオペレーションであれば事前にポリシーを定義可能 • オペレーションが定型化できない／されていないのに権限を制限すると業 務に支障が・・・
- 38. 38IAM Safetyの仕組み 必要な時に「一時的に」特権へ昇格させる機能 • 指定したIAM User/IAM Roleの権限を制御 • 通常時は禁止したいアクションをポリシーをアタッチ • 特権を付与する＝禁止したいアクションを定義したポリシーをデタッチ
- 40. 40制限するためのIAM Groupを作成 Deny PolicyをアタッチするIAM Groupを作成 （制限するIAM Userはこのグループのメンバーになる）
- 42. 42 IPアドレスの集中管理
- 43. 43マルチアカウント戦略 Architecting Security & Governance across your AWS Landing Zone (SEC303-R1) - AWS re:Invent 2018 https://www.slideshare.net/AmazonWebServices/repeat-1-architecting-security-governance-across-your-aws-landing-zone-sec303r1-aws-reinvent-2018/59
- 44. 44なぜマルチアカウント戦略を採用するのか （主な）理由 • コストの識別 • 権限の分離 マルチアカウントの弊害 • 各アカウントが適切に利用されているのか把握するのが難しい （そもそも、妥当な設定は？） • せめて、重要なリソースだけでも保護したい・・・ • アカウントに共通の設定を実施する手間 • 特定の拠点のIPアドレスなど
- 45. 45IP List Dome9上で管理されるIPアドレス／ネットワークアドレスの 集合 • Dome9上でのSecurity Groupの設定に利用可能 • IP Listを変更すれば、Security Groupの設定にも反映 • 複数のAWSアカウントに対して、 IP Listの変更というワンアクションで設定を展開可能
- 46. 46IP List IP Listを参照している Security Group IP Listと同じアドレスに アクセスを許可している Security Group
- 47. 47IP List による Security Group の設定
- 48. 48 デモ
- 49. 49デモ 1. Compliance & Governance によるAWSアカウントの評価 (PCI DSS 3.2) 2. Network Security (Clarity) によるSecurity Groupの可視化 3. Network Security (Tamper Protection) によるSecurity Groupの保護 4. Dynamic Accessによる一時的なアクセス許可 5. IAM Safety による一時的な特権の付与 6. Network Security (IP List) によるIPアドレスの集中管理
- 50. 50 Compliance & Governance による AWSアカウントの評価
- 51. 51Compliance & Governance 前提条件 • Dome9にAWSアカウントを登録済み（保護モード） デモの流れ • PCI DSS 3.2 に準拠したルールセットで評価を実行 • 評価結果を確認
- 52. 52 Demo
- 53. 53 Network Security (Clarity) による Security Groupの可視化
- 54. 54Clarity 前提条件 • Dome9にAWSアカウントを登録済み（保護モード） • 評価対象を構築済み デモの流れ • 作成したVPCのSecurity Groupを可視化 • リソース間のリレーション（アクセスできる／アクセスされうる）を確認
- 55. 55可視化の対象
- 56. 56 Demo
- 58. 58Tamper Protection 前提条件 • Dome9にAWSアカウントを登録済み（保護モード） • 管理対象のSecurity Groupを作成済み デモの流れ • Security Groupの保護設定を有効化 • AWSのマネージメントコンソールからの設定追加がロールバックされること を確認
- 59. 59 Demo
- 61. 61Dynamic Access 前提条件 • Dome9にAWSアカウントを登録済み（保護モード） • 管理対象のSecurity Groupを作成済み デモの流れ • Security Groupの保護設定を有効化 • Dynamic Accessのための設定を追加 • Invitationを送信（今回はリンクの作成） • Dynamic Accessによってアクセス許可設定が追加されることを確認
- 62. 62 Demo
- 64. 64デモの流れ 前提条件 • Dome9にAWSアカウントを登録済み（保護モード） • IAM Safety用のIAM GroupおよびIAM Roleは作成済み デモの流れ • 特権が必要な操作ができることを確認 • IAM UserをIAM Safetyによる管理対象に追加 • 特権が必要な操作ができなくなることを確認 • IAM Userに対して一時的に特権を付与 • 特権が必要な操作ができるようになることを確認
- 65. 65 Demo
- 66. 66 Network Security (IP List) による IPアドレスの集中管理
- 67. 67 前提条件 • IP Listを利用するSecurity Groupは作成済み デモの流れ • IP Listを作成 • IP Listを利用してSecurity Groupにアクセス許可を追加 • Security Groupを確認（@AWSマネージメントコンソール） • IP Listを変更 • Security Groupを確認（@AWSマネージメントコンソール）
- 68. 68 Demo
- 69. 69 まとめ
- 70. 70まとめ リスクの発見と予防を実現 • 容易にリスクを洗い出すことが可能 （検出されたリスクを評価し、是正の要否を判断する必要はある） • ネットワークの可視化 （Security Groupから通信可能な経路・データフローを表示） 大量のアカウントの管理 / 統制を少ない工数で実現 • 一時的なアクセス許可の設定やIPアドレスの集中管理が容易 第三者の監査と認証の維持 / 運用の工数を削減 • 定義済みのルールセットを用いてリスクを発見
- 72. 72そのほかの機能 いろいろありますのでぜひお試しください • 独自のルールセットの作成／複製 • Complianceチェックの定期実行、通知 • Complianceチェックの除外設定 • ポリシーレポート • 認証情報レポート • VPC FlowLogsに対するフィルタリング • Security Hubとの連携（Preview） • CloudFormationテンプレートに対するセキュリティチェック （Preview）
- 74. 74