クラウド セキュリティ プログラムを確立するためのベスト プラクティスと教訓

Tenable のクラウドセキュリティプログラムを開発するなかで、私たち情報セキュリティチームは多くの疑問を抱き、興味深い課題に直面してきました。 その過程で、私たちは貴重な教訓を学び、重要なベストプラクティスを取り入れてきました。 このブログ記事では、私たちが Tenable Cloud Security を使用してクラウドセキュリティプログラムをどのように実装したかについて説明し、役に立つと思われる推奨事項を紹介します。

クラウド環境が複雑化し、セキュリティ脅威も増加しているため、クラウドセキュリティは多くの組織にとって最優先事項となっています。 こうしたセキュリティリスクの特定と管理を行うために、多くの組織がクラウドネイティブアプリケーション保護プラットフォーム (CNAPP) ソリューションを利用しています。 ただし、最適なツールを導入した場合でも、堅牢なクラウドセキュリティ態勢を長期的にわたって維持するには効果的な戦略が必要です。

ここ数年、私たち Tenable の情報セキュリティチームは、クラウドセキュリティの課題に数多く直面し、効果的なクラウドセキュリティプログラムの開発方法について貴重な教訓を学んできました。 多くのお客様と同様、私たちも責任、修正、メトリクス、報告に関して多くの疑問を抱いてきました。 

このブログ記事では、私たちが Tenable Cloud Security を使用してクラウドセキュリティプログラムをどのように実装したかについて説明し、皆さま独自のセキュリティプログラムの拡張に役に立つと思われる推奨事項をご紹介します。 クラウドアカウントの可視性と所有権の確立や、レポートを使用したアカウントのコンプライアンス確保の重要性などの課題を取り上げます。 さらに、修正作業の優先順位付けに役立つ推奨事項もご提案します。 

クラウドアカウントの設定

クラウドフットプリントの規模にかかわらず、自分がどのようなクラウドアカウントを持っているかを把握しておくことは重要です。 本番用、開発用、サンドボックス用のアカウント、あるいはそれらの組み合わせのいずれを持っている場合でも、そのアカウント内でどのようなリソースが実行され、アカウントがどのように使用されているかを見極めることが大事です。 

たとえば、クラウドフットプリントを完全に把握できていないと、シャドー IT、従業員の離職、最近の合併や買収などの問題が原因で、リソースに過剰な権限が与えられたり、一般アクセスが可能な状態になってしまったりしがちです。 アカウントの利用実態を知ることで、Tenable Cloud Security 内でアカウントを効果的に編成し、管理することができます。

アカウントをオンボーディングする前に、Tenable Cloud Security 内でアカウントをどのように構成するかを決めることが重要です。 複数の組織または個々のアカウントのどちらをオンボーディングする場合でも、コンソール内でフォルダーを使用して簡単に構造化できます。 フォルダーにより、事業部門や、本番環境と開発環境のどちらであるかに基づいたアカウントの論理的なグループ化がしやすくなります。

Amazon AWS、Microsoft Azure、Google Cloud Platform (GCP) 組織、または Oracle Cloud Infrastructure (OCI) テナンシをオンボーディングしている場合、新しいアカウントを自動的にオンボーディングし、クラウド環境の変化に応じてフォルダー構造を更新するように設定できます。 

アカウント所有者の決定

アカウントのオンボーディングが完了したら、次はアカウントに所有者を割り当てる必要があります。 アカウント所有者は、そのアカウントの一次連絡先および意思決定者の役割を担います。 所有者は、アカウント全体のセキュリティを確保する責任を負い、所有権に関係なく、アカウント内のすべての除外リソースに関するリスクを容認します。 

アカウントの所有者は少なくとも 2 人設定し、うち 1 人はマネージャー以上とすることをお勧めします。 このように設定することで、優れたバックアップソリューションを備えられるだけでなく、コストの問題に関する意思決定や、セキュリティ上の質問への対応、アカウントのアクセス申請の承認が可能な窓口も提供できます。 

アカウント所有者の特定と選定を進める際、各アカウントに対応するメールアドレスを取得することもお勧めします。 そうすれば、セキュリティチームはアカウントに関連する問題について、アカウントの所有者に問い合わせることができます。 また、Tenable Cloud Security 内でレポートを作成し、定期的にチームに自動メール送信を行うこともできます。 

アカウント所有者の選定は、使用するクラウド環境の数によっては時間がかかることがあります。 組織の変更にあわせて、CNAPP プラットフォーム外の、すべてのチームがアクセスして確認できる一元管理された場所で、アカウントと所有者を記録することをお勧めします。 

アクセス権の設定

アカウントの所有者を選定したら、次のステップは、アカウントにアクセスする必要があるユーザーの設定です。 まず、各アカウントにアクセスしているのはどのチームか、そのアクセスレベル、チームが管理しているリソースの数を確認することをお勧めします。 この情報は、各アカウントのプライマリチームを決定し、Tenable Cloud Security 内で必要とする権限を判断するのに役立ちます。 

ほとんどの場合、プライマリチームにはアカウント所有者と関連するチームメンバーの両方が含まれます。 ただし、一部のアカウントへのアクセスは、アカウント所有者のみに限定される場合があります。 たとえば、サイト信頼性エンジニアリング (SRE) チームが本番アカウント内の多くのリソースを管理し、完全な管理者権限を持っている場合、そのチームを Tenable Cloud Security 内のプライマリチームとして設定します。

プライマリチームのメンバーには Collaborator ロールが割り当てられます。このロールによって、ポリシーの除外を完全に管理し、リソースに手動ラベルを追加できるようになります。 このロールを使用することで、アカウントへの Viewer ロールアクセス権を持つ他のチームが、自身が所有しているかどうか定かではない検出結果に対して、無断で例外を追加することを防ぐことができます。

複数のチームがアカウントにアクセスする場合、Tenable Cloud Security 内でセカンダリチームにアクセス権を提供することになる場合があります。 セカンダリチームには、リソースを管理するアカウントの Viewer ロールが割り当てられます。 このロールは、アカウント内のリソースを管理するエンジニアリングチームが複数ある場合に最適です。このロールが割り当てられたチームは検出結果の確認と修正を行うことができます。 

最後に、IT または情報セキュリティのチームには、Tenable Cloud Security の Administrator ロールが付与されます。 このアクセス権により、コンソール内でのアカウントのオンボーディング、設定や統合の構成、JIT アクセスの管理が可能になります。

クラウドアカウントと同様に、すべてのチームがリソースへのログインやアクセスの権限を持つ必要はありません。 Tenable Cloud Security を使用してアクセス制御を実装すると、許可されたチームメンバーが、承認されたアカウントに確実にアクセスできるようになります。 

コンプライアンスの監視

クラウドセキュリティプログラムの主要な側面の 1 つは、業界標準へのコンプライアンスを確保して、法律、規制、ビジネスの要件を満たすことです。

Tenable Cloud Security は多くのオプションを提供し、Center for Internet Security (CIS) のベンチマーク、一般データ保護規則 (GDPR)、NIST のサイバーセキュリティフレームワーク (CSF) といった標準に照らし合わせてセキュリティ態勢を継続的に監視できるよう支援しています。

これらの標準を有効にする前に、保護する必要があるリソースやデータの種類を決定する必要があります。 

Kubernetes クラスターを実行している場合は、Kubernetes とコンテナ環境の可視性とカバレッジを強化するために、クラスターを Tenable Cloud Security にオンボーディングすることをお勧めします。 Kubernetes Security Posture Management (KSPM) カバレッジを実装する場合は、Helm チャートを経由する、またはクラスター内でネットワークアクセス権限を付与する、という 2 つの便利な方法があります。 アカウント内で仮想マシンやコンテナを実行している場合、ワークロード保護を有効にすることで、クラウドワークロード内の脆弱性を特定して報告することができます。 

コンプライアンス基準を有効にした後、どのアカウントでコンプライアンスレポートを有効にするかを決定する必要があります。 「Open Findings (未解決の検出結果)」 レポートタイプを使用して「スケジュールされたレポート」を追加すると、アカウントとコンプライアンス基準を選択し、配信時間を設定して、定期的に CSV 添付ファイルを送信するためのメールアドレスを追加できます。 

コンソール内で、アカウントにアクセスできるチームメンバーは、レポート履歴セクションにアーカイブされている過去のレポートをダウンロードできます。 チームメンバーが Tenable Cloud Security に直接アクセスできなくても、全く問題ありません。 CSV 添付ファイル内の情報には該当するすべての情報が含まれており、リソースの所在地、深刻度レベル、アカウント内の検出結果を修正する手順を誰でもすぐに確認できます。

検出結果の確認と修正

Tenable Cloud Security での検出結果を確認する際、チームから、どこから着手すべきか、修正作業の優先順位はどのように決めればよいのかという質問がよく寄せられます。 私たちは、まずそのアカウント内のリソースを確認し、タグフィルターを使用して管理対象のリソースを強調表示することをチームに推奨しています。 

一貫性のあるタグ付けポリシーを持つことは、クラウドセキュリティプログラムを成功させるうえで非常に重要です。組織の変化に応じてチームがコスト、チーム、目的などのパラメーターによってリソースを管理できるからです。 リソースに一貫性のあるタグ付けを行わないと、コストの増加やインシデント対応時間の長期化につながり、コンプライアンスへの取り組みにも影響する可能性があります。

クラウドインフラ内に一貫性のあるタグ付けポリシーが導入されていない場合は、Tenable Cloud Security のラベル機能がその取り組みに役立つ優れたオプションを提供します。 Collaborator または Administrator のロールによるアクセス権限を持つチームは、タグに基づいて適用される自動ラベル、またはリソースに適用される手動ラベルを使用できます。

そのため、IT、エンジニアリングなどのチームがアカウント内のリソースを管理している場合、または対象のリソースがタグ付けをサポートしていない場合、ラベルの使用はリソース所有者をすばやく特定するための優れたソリューションとなり、修正作業に役立ちます。

検出結果に対処する準備が整ったら、以下の順序で修正作業の優先順位を付けることをお勧めします。 

• 重要で深刻度の高い検出結果のリソースに対処する。 
• 古い、あるいは使用期限が近づいているオペレーティングシステムにパッチを適用する。
• 過剰に権限が付与されたリソースを確認し、修正する。
• 露出した機密情報を削除する。
• 未使用および非アクティブ状態のリソースをすべて削除する。

また、Tenable Cloud Security では、アカウント内の特定の条件に基づいて、E メールや Slack 経由でリソースに関するアラートをチームメンバーに送信することもできます。 こういった提案は、すぐに対処すべきものと、後でも対処できるものを判別するのに役立つ良い出発点となります。

除外事項

どのような組織にも、さまざまな理由で対処されないままとなるセキュリティ上の問題が常に存在します。 検出結果の修正後に、例外を追加する必要があるリソースが存在する場合があります。 Tenable Cloud Security では、組織の要件を満たせるよう、恒久的な例外にするか、一時的な例外にするかを選べます。恒久的な例外については、除外が認められ許容可能とみなされる次の 2 つのユースケースを推奨します。

• リスクを軽減するための補完コントロールが導入されている。
• 明確なビジネスユースケースの要件のために「Failed」の検出結果を修正できない。 

企業ポリシーの有無に関係なく、アカウントの所有者が、管理しているアカウントで除外されたリソースに責任を負い続けることが重要です。 一度除外された検出結果は、リスク承認プロセスの一部となり、全体的なコンプライアンススコアに影響を与えます。 

Tenable Cloud Security では、いくつかの方法で除外を追加できます。 恒久的な除外の例としては、AWS EC2 インスタンス、バケット、ストレージアカウントなど、お客様が使用する可能性がある公開リソースが挙げられます。 時間ベースの除外には、将来のスプリントでパッチ適用可能な脆弱性を持つリソースが考えられます。 期限を過ぎるとその例外は失効し、リソース検出結果は「Open Findings (未解決の検出結果)」キューに戻ります。

また、各ポリシーの除外を管理するオプションを使用して、リソースを個別またはパターン別に除外することもできます。 

パターン別にリソースを除外する場合、Amazon リソース名 (ARN) 別、名前別、タグ別のオプションを追加できます。 この機能を使用すると、組織全体の複数のリソースを一度に除外することができます。

主要業績評価指標 (KPI)

検出結果に対処したら、次のステップは、コンプライアンス指標とパフォーマンスを長期的に測定することです。 主要業績評価指標 (KPI) は、既知のコンプライアンス基準と照らし合わせて、組織のコンプライアンスの取り組みを評価するために使用されます。 成熟したクラウドセキュリティプログラムの一環として、KPI 指標を毎月追跡することは成功への第一歩となります。 また、リーダーシップチームと協力して、プログラムの一環として監視すべき一連の KPI を決定して合意に至ることも重要です。

KPI の一例として、合格するためにコンプライアンススコアを 85% 以上に維持することが挙げられます。 こういった KPI が決定され、合意されると、チームは Tenable Cloud Security コンソールの [Dashboard] (ダッシュボード) セクションでその変化を追跡できます。

このような変化を監視するには、まずコンソールの右上隅で対象アカウントを選択します。 [Dashboard] セクションで [Compliance] (コンプライアンス) ウィジェットを確認し、過去 7 日、30 日、90 日間の変更を監視します。

[Compliance] セクションではコンプライアンススコアの内訳も確認できます。

クラウドセキュリティプログラムをアカウント所有者に提示

最後のステップとして、アカウント所有者と面談して、クラウドセキュリティプログラムの詳細について検討することをお勧めします。 この情報を提示する際には、このプログラムを実施する理由と、アカウント所有者が責任をもって確保する対象について話し合うことが重要です。 アカウント所有者は、クラウドセキュリティプログラムがデータのプライバシーと規制遵守を保証し、セキュリティリスクから保護できるよう設計されていることを認識しておくべきです。

また、アカウント所有者に、Tenable Cloud Security 内で管理およびアクセスできるアカウントについて伝えることも重要です。 コンプライアンスレポートには、アカウント所有者に提供される内容の詳細を含める必要があります。 検出結果を確認して修正し、チームがどのように対策に着手したらよいかを提案すれば、役立つことでしょう。 また、除外プロセスや、組織で許容されるユースケースに関する情報も記載します。 最後に、アカウント所有者が目標とすべき KPI を明記します。 

アカウント名、適用されるコンプライアンス基準、アカウント所有者を含む社内資料ページを作成すると、現在と将来のアカウント所有者の参考資料として役立ちます。

まとめ

クラウドセキュリティプログラムの策定は 1 回限りの展開では済みません。 強力なプログラムを維持するには絶え間ない努力が求められ、組織内のすべてのチームからの支援が必要です。 今回ご紹介した教訓やベストプラクティスが、当社の包括的な Tenable Cloud Security ソリューションを活用したクラウドセキュリティプログラム戦略の強化の一助となれば幸いです。

Tenable Cloud Security の詳細と、クラウドセキュリティプログラムの強化にTenable Cloud Security を活用する方法については、ホワイトペーパー「クラウドの強化: CNAPP セキュリティをマスターする」とブログ「スキマ時間でわかる CNAPP」をご覧ください。