この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、AWSのセキュリティ対策やってますか？(挨拶
今回はオンライン開催されたJAWS DAYS 2020の登壇資料を公開しつつ、解説を行っていきます。
資料
動画
解説
資料のコンセプト
AWSセキュリティの文脈で、AWSマネジメント & ガバナンスにフォーカスした話をしています。
初心者でも順を追って辿れるように(優しく簡単に、ではなく)まとめるようにしています。参考文献をたくさん載せているので、これらを見つつ知識と技術を吸収できるようにしています。
この資料をまとめる上で僕がやりたいこと
エモく言うとAWSを活用した幸せな未来の実現を目指したい。それができる人を増やしたい、です。
前置き
セキュリティ対策は大変ですけど、きちんと理解しながらやっていけばいいです。
一口にセキュリティ対策と言ってもいろんなベクトルがあるということを意識すると理解しやすくなると思います。
セキュリティはゲート型の対策ではなくガードレール型のセキュリティを目指しましょう。セキュリティはビジネスを阻害するものではありません。
1.AWSセキュリティ基礎と最新情報
だいたい下記に全部まとまっていますｗ
「AWSでのセキュリティ対策全部盛り[初級から中級まで]」をDevelopers.IO 2019 TOKYOで発表しました #cmdevio
基本的にはAWSレイヤーとOS/ミドル/アプリレイヤーの2つのレイヤーがあると意識すればいいです。
AWSご利用開始時に最低限おさえておきたい10のことは鉄板なので確実に確認して有効化しましょう。他にもWell-Architectedフレームワークはセキュリティに限らずAWS自身がまとめたベストプラクティス集なので活用しましょう。
AWSのセキュリティベストプラクティスはAWSのセキュリティを意識する上で確実に押さえる内容ですが、下記の補足ブログと一緒に見るとわかりやすいと思います。
IAMは最重要事項なので確実に覚えましょう。AWSを利用するユーザーには確実に学習してもらいましょう。
AWS上で開発する際には万が一を防ぐためにgit-secretsをすべての端末に導入しましょう。
AWSの薄い本 IAMのマニアックな話 - 佐々木拓郎のオンライン本屋 - BOOTHは秘伝のタレも惜しみなく紹介されているいい本です。是非買いましょう。(私に一切インセンティブとかはないですがｗ)
他にも有効化する必要があるサービスがいくつかあります。
- CloudTrail
- Config
- GuardDuty
有効化していきましょう。
AWSセキュリティ基礎や構築する環境やその設計基礎は過去のJAWS DAYSでも話しているのでこちらも参考にしてください。
セキュアなWeb環境の一例は下記のような感じ。
AWSのマネジメント & ガバナンス
AWSのセキュリティ対策については上記で説明したとおり様々な情報があるのでそれを実践していけばいいです。
しかしながら、すべてのAWSユーザーにこれを実践してもらうのは大変です。社内での教育も行っていく必要もありますが、限度がありますので、そんな時に必要な考え方がガードレールです。
今回は3つのガードレールを実装できるサービスにフォーカスします。
- Control Tower
- 大規模なアカウントのガバナンスを提供
- Config Rules
- 適切な設定が行われているか監視してアラートする
- Security Hub
- セキュリティアラートを集約したり、コンプライアンスチェックを行う
順に説明していきます。
Control Tower
Control Towerを理解するためにはマルチアカウント戦略から理解する必要があります。様々な環境をAWS上で構築する場合は、基本的にシステム + ステージで分割していったほうがいいです。これはセキュリティの境界を明確にするためです。よくあるのは、開発環境がセキュリティ意識が低いため悪意のある第三者に乗っ取られて、そこから本番環境のデータも侵害される、ということがあります。
AWS OrganizationsはAWSの複数のアカウントを束ねて管理するためのサービスですが、利用状況によって制約があることがあるので注意が必要です。
Control TowerはLanding Zoneと呼ばれるマルチアカウントを束ねて管理する仕組みのマネージドサービスです。
まだ東京リージョンに来ていないサービスで、機能的な制約もいくつかありますが、もっと利用しやすくなっていくと思うのでこのサービスについてキャッチアップしていくといいと思います。現状では同じような仕組みをConfig Rulesなどを使って実践していきましょう。
Config Rules
変更管理を行うAWS Configの機能の1つで、決められたルールから逸脱した設定を行ったらアラートを出します。
AWSが提供しているマネージドルールと、自分たちでカスタマイズできるカスタムルームがあります。推奨ルールはこちらにもまとめています。
そして、違反を検知したら自動修復できるのが一番いいところです！
便利だね！安全だね！
ぜひこれを目指してください。
おすすめのルールはここにも書いておきます。
- 超おすすめ
- restricted-ssh: セキュリティグループに0.0.0.0/0:22が付いていないか
- cloudtrail-enabled: CloudTrailが有効になっているか
- guardduty-enabled-centralized: GuardDutyが有効になっているか
- iam-root-access-key-check: rootのアクセスキーがないか
- iam-user-mfa-enabled: IAMユーザーのMFAが有効か
- mfa-enabled-for-iam-console-access: コンソールログインユーザーがMFA有効か
- root-account-mfa-enabled: ルートアカウントでMFAが有効か
- ebs-snapshot-public-restorable-check: EBSがパブリック復元できないか
- rds-instance-public-access-check: RDSがパブリック・アクセスできないか
- 準おすすめ
- elb-logging-enabled: ELBでロギングが有効か
- cloud-trail-cloud-watch-logs-enabled: CloudTrailのLogs出力が有効か
- cloud-trail-log-file-validation-enabled: ログファイル検証が有効か
- elb-deletion-protection-enabled: ELBの削除保護が有効か
- db-instance-backup-enabled: DBインスタンスのバックアップが有効か
- rds-multi-az-support: RDSがマルチAZか
- vpc-default-security-group-closed：defaultセキュリティグループが無効か
- guardduty-non-archived-findings: GuardDutyにアーカイブされていないFindingsがあるか
Security Hub
セキュリティアラートとコンプライアンスチェックができるサービスです。
コンプライアンスチェックは2種類あります。
- CIS AWS Foundations Benchmark v1.2.0
- PCI DSS v3.2.1
単純に100%を目指すことは現実的ではないので項目をチューニングして利用したほうがいいです。
参考ですが、Dome9というSaaSのサービスを使うと、よりいろんなコンプライアンスチェックをしたりIAMやSecurity Groupの操作を限定したりできるのでこちらもおすすめです。
3. Security HubとConfig Rules実践
Security HubのコンプライアンスルールチューニングとConfig Rulesの自動修復を実践していくための具体的な話をしていきます。
Security Hubのチューニング
- Security Hubのコンプライアンスのいいところ
- 設定をまとめて有効化
- 達成率を簡単に可視化
- イベントの管理が楽
- トラッキングが簡単
- 気をつけること
- 全項目達成すればいいみたいな盲目的な使い方をしない
- すべてのルールを満たすのはやりすぎなことが多いのでチューニング(必要ないものを無効化)する
- ルールの適用範囲を調整できない(全てのリソースが対象になる)ので範囲を限定する
- アカウント分割する
- 手動作成したルールに置き換える
有効化はポチッとするだけなので簡単です。
ルールは2種類ありますが、一般的な環境では両方併用すればいいです。PCI DSSの要件がなくても便利なチェック項目なのでPCI DSSのルールも利用しましょう。
それぞれ、やりすぎかな？という項目がいくつかあるのでそれらを無効化してください。対象項目は下記でしっかり説明しています。
Config Rules自動修復
違反があった設定を自動修復します。AWSの恩恵を非常に受けられる使い方なのでぜひこれを実現することを目指してください。
Config Rulesは下記のように動作します。
- Configではリソースを中心にイベント(証跡)を記録する
- ルールのチェックタイミングは設定変更(イベント発生時)か定期的
- 対象リソースをタグで絞ったりできる
違反を検知したあとの自動修復にはSystems Manager(SSM) Automationという機能で実現しています。AutomationはAutomationドキュメントという定義ファイルに沿った動作をします。
今回はチェックするConfig Rulesの例としてrestricted-sshというルールにフォーカスしています。このルールはSecurity Groupがsshのフルアクセス(0.0.0.0/0)を許可している場合に検知するルールです。
この際に利用できるAutomationドキュメントはAWS-DisablePublicAccessForSecurityGroupというものです。このドキュメントでは、指定したSecurity GroupからsshやRDPが0.0.0.0/0からのアクセス許可を削除するAPIを実行します。細かい動作は下記を確認してください。
Automationのドキュメントはyamlで定義されていて各種AWSのAPIを実行したり、LambdaやCloudFormationを実行することができます。前はドキュメントを手動で全部書く必要があり大変でしたが、Builderができて書きやすくなったので、より自分たちの要件にあったドキュメントを作成して使ってみてください。
あとは、Configの準拠状況はConfig アグリゲーターを利用することによりマルチアカウント/マルチリージョンでまとめて見ることができますのでこれを利用して、マルチアカウント戦略を実践しつつまとめて管理しましょう。
まとめ
まずはアカウント戦略を理解して、アカウントを分割していきましょう。
マルチアカウントでガバナンスを効かせるためにConfig RulesやSecurity Hubを活用していきましょう。
そして自動化です。Config Rulesの自動修復を活用してより幸せなガードレール環境を目指しましょう！
12
