「基本から分かる！AWSセキュリティ運用の考え方と任せ方」というタイトルで登壇しました

こんにちは、臼田です。

みなさん、AWSのセキュリティ運用してますか？(挨拶

今回は属人化からの解放！継続的に回るAWSセキュリティ運用のつくり方というイベントで登壇した内容の解説です。

資料

イベント概要

AWSのセキュリティ運用では、Security HubやGuardDutyを導入したものの、検知結果の確認や優先度判断、対応まで手が回らないという声を多く伺います。

アラート件数が多く、確認・判断しきれないまま後回しになっている
日々のAWS運用と並行して、限られた担当者がセキュリティ対応も担っている
AWS Organizations／Control Tower導入後の監視・統制強化まで十分に進められていない
対応手順や判断基準が個人に依存し、担当変更時に運用が滞りやすい
本ウェビナーでは、AWS Security Heroの称号を持つ臼田が、こうした課題に対して“本来あるべき運用監視の姿”を解説し、AWS運用でよくある「時間」と「人材」の壁を整理します。
評価・設計・導入・運用までを一気通貫で支援する「クラウドセキュリティ運用総合支援サービス」の仕組みと、実際の導入事例をご紹介します。

自社で抱え込まず、任せられる部分を任せる——
自社に合ったAWSセキュリティ運用のベストプラクティスを探っていただける内容です。

登壇概要

「セキュリティ対策をしっかりやりたい！でもどこからやればいいの？」という相談が私のところによく届きます。
一口にセキュリティと言ってもその範囲は広範で、とても1人の担当者が検討し対応するには難しい領域です。そしてセキュリティ対策は一度やって終わりではなく、継続的に運用してセキュアな状態を保つ必要があります。このセッションではAWSセキュリティの基礎から説明し、どのようにAWS環境をセキュアに保つか、どのようにクラスメソッドがお客様のAWSセキュリティ運用を支援できるかわかりやすく解説します。

解説

後ほど

質問回答

ウェビナー中に頂いた質問に回答します。

他組織のAWSアカウントから自組織のアカウントのリソースへアクセスさせる場合、①IAMロールを利用したクロスアカウント②アクセスキーを用いるどちらがベストプラクティスになりますでしょうか。①の場合AWSアカウントIDを他組織へ共有する必要があるため気になっています。

1が推奨です。2の手法でアクセスキーを作成すると、永続的なキーが発行されこれが漏洩するだけですぐに悪用が開始されてしまいます。

一方IAM Roleを利用したクロスアカウントのアクセスは連携先組織のAWS上でMFAやセキュリティの管理をしっかり適用できていれば、一時的な認証情報のみでアクセスができてセキュリティの耐性が上がります。アカウントIDの共有それ自体はセキュリティ的に問題になるわけではありませんので、危険なアクセスキーの利用を避ける方針が適切です。

AWS Security Hub CSPMのセキュリティ基準を使用すれば、一般的な準拠ルール（コントロール）をカバーできると理解しています。 そうすると、「AWS Config側で準拠ルールを敢えて設定する必要ないのでは？」と思うのですが、この考え方は合っていますでしょうか？ （CSPM側とConfig側で二重でチェックしているように思います。）

はい、基本的には合っています。AWS Security Hub CSPMが内部的にAWS Configを利用してルールを設定してくれるので、一般的なセキュリティのルールは全部そちらに任せてよいです。そのうえで、自社独自のルールを整備したりする場合などに、個別にAWS Configのルールを使っていく、という考え方の順序でOKです。

セキュリティ対策はやればやるほどコストが増大します。 セキュリティ対策のベストプラクティスとしては、「厳しく→緩く」と「緩く→厳しく」のどちらが適切でしょうか？

コストとのバランスは非常に難しいところですが、コストを保護してビジネスを守っていくところも広義のセキュリティ対策でもあります。

一概にどちらが良い悪いというのは決めづらいのですが、1つ考え方としては組織の文化に合わせて選択いただくとよいです。

例えばAWSやアプリケーション開発を行うエンジニアが多数在籍しておりセキュリティに関するレベル感がまちまちであれば、それぞれの自走に任せすぎると崩壊しがちである、と判断される場合には厳しめにするところから。自走が上手く回っている組織なら緩めから始めてルール整備を積み上げていく、などの戦略が取れます。

ConfigやCloudTrailの通知が多く確認しきれないのですが、よい対策はあるでしょうか？

AWS CloudTrail/AWS Configは基本的にログを直接追う必要はありません。保存のみでOKです。それらのログや検出を活用してセキュリティ的な判断を行える、Amazon GuardDutyやAWS Security Hub CSPMがその役割を負いますので、その結果を見ていけばOKです。

Inspectorの検出結果が多く、どのように対応を進めればよいか、迷っています。SecurityHubと同様にカテゴライズ、重大性等をベースに整理や対応方針決めから実施するほうがよろしいでしょうか。

Inspectorの検出は脆弱性として登録されているものが全て出てくるためご認識の通り対応の難しい領域です。まず大きな方針としては、パッチが提供されているものはなるべく更新していく、というところで検出量を減らしてリスクを下げやすい方向に舵を切っていただきつつ、パッケージマネージャ等で対応が難しい(個別にバージョンアップが必要なもの)やパッチがそもそもないものは調査して判断していく必要があります。こちらは特にCriticalかつ悪用が始まっているものを優先度を上げて、緩和策も含めて検討していくことになります。

Inspector,GuardDutyをEventBridgeで設定したらメールで大量通知された。現在は停止中である。また再開して、大量メール受信が鳴らないように設定したい。具体的にはどんなことをやればよいか？

セキュリティサービス有効化後、すぐに通知を入れると大量に届くケースは多いです。まずは潰しこみを行ってから通知を入れていく方針がよいです。
検出内容を1つずつ確認して潰しこみしていきましょう！

特定のScurityHubのルールの一部をメンバーアカウントに通知をする仕組みを敷いています。ルールの見直しを行う際の、タイミング、頻度にべスプラはありますか

AWS Security Hub CSPMのルール側は基本的に変更がありませんので、ルールの変更等に伴う見直しは必要ありません。

通知から是正までが問題なく運用できていればそこを直接見直す必要はありませんが、検出頻度が多いようであれば、どちらかというと運用ルール・そもそもの設計方針をガイドラインとして整備し、誤った設定が起きないようにして検出自体を減らす方向も合わせて進めていただくとよいでしょう。

AWSセキュリティ運用支援に興味があります。 クラメソさんの一律割引プランv2と組織管理プランv2で複数のAWSアカウントを運用中ですが、プランによって支援を受けやすいor制限があるなどはありますでしょうか？

提示頂いた2つのプランは、お客様がAWS Organizationsを直接利用できるかできないか、という違いがありますが、基本的にどちらもAWSセキュリティ運用に関わる支援は提供可能です。AWS Organizationsを利用することでセキュリティ設定の一括展開や集約がやりやすいメリットはありますが、AWS Organizationsが直接利用できなくてもCloudFormation StackSetsなどで似たような事はできますので、大きな制約にはなりません。

これまで、旧Security Hub（現CSPM）しか利用したことがないのですが、CSPMは項目も多いのでそれだけで使用するよりも、新Security Hubも使用して複合的なリスクで判断したほうが良いのではと思ったのですがいかがでしょうか？

新しいAWS Security Hubを利用していただくと、AWS Security Hub CSPM以外にも、Amazon GuardDutyやAmazon Inspectorなどから収集した情報を元に、複合的なリスクを評価してより優先度の高い問題を可視化し対処していくことが可能です。

ただ、対応していく際には従来通りそれぞれのサービスで検出した内容に対処するのと同じであるため、必ずしも必要なサービスではありません。

コストも追加がかかることから、各サービス単体で運用が回っている場合にはあまり必要性が感じられないかもしれません。目安としては、コストをかけてでもたくさんある通知を優先度を付けて対処したい場合や、より深刻なものをわかりやすく発見したい場合、対応手順を詳細に教えてほしい場合などには新しいAWS Security Hubを活用するメリットが高くなります。

AWS Security Hub CSPMを有効化する際に有効化するセキュリティ基準を選択しますが、推奨はありますか？ デフォルトで「AWS 基礎セキュリティのベストプラクティス v1.0.0 を有効にする」と「CIS AWS Foundations Benchmark v1.2.0 を有効にする」にチェックが入っています。

「AWS 基礎セキュリティのベストプラクティス v1.0.0」のみを有効化すればよいです。CISは歴史的な経緯でデフォルトとなっていますが、通常の環境では必要ありません。

残りのセキュリティ基準は、それらの基準を会社として活用している場合のみ利用すればOKです。

現在、セキュリティチェックをTrusted Advisorで行っていますが、Security Hub SCPM を導入しないと拾いきれない内容も多いということでしょうか。

はい、サポートを利用していれば無償で利用できるAWS Trusted Advisorの内容よりも多数のリソース種類をカバーした検出が可能であり、また細かいパラメータの調整や抑制設定、自動修復など運用に役立つ様々な機能があり、AWS Security Hub CSPMはすべてのAWS環境で必須のサービスです。

CSPMで通知されたけど、対応忘れで再通知されず 昨今のセキュリティ総チェックでやっと見つかるパターンもあり、Security Hubの通知運用だけではつらいなーと思っていますが、アカウントがいっぱいあるとSecurity Hubの運用自体がつらくて困っています

はい、AWSでは特に検出した問題や脅威などの状況を管理するチケッティング・チケット管理機能がありません。これは通常企業が保有するJiraやBacklogなどのチケット管理システムと連携して利用することが想定されています。

通知を抑制する仕組みや通知を減らすガイドラインの整備などの取組と合わせて対応していく必要があります。

ただこのあたりを含め、環境規模が大きくなってくるとCNAPP系のサードパーティのソリューションを活用することでより便利になることもあるため、そちらも含めて検討いただくとよいと思います。

まとめ

AWSセキュリティを適切に行なっていくのは大変ですが、基礎からしっかり積み上げて行く必要があります。この道筋自体に近道はありませんので、頑張ってやっていきましょう！