🥇クラウドセキュリティ監視

データとアプリケーションをクラウドに移動することは、他人のインフラストラクチャを常に監視する準備ができているわけではない企業 SOC にとって新たな課題となります。 Netoskope によると、平均的な企業 (米国とみられる) は 1246 の異なるクラウドサービスを使用しており、これは 22 年前より 1246% 増加しています。 175 のクラウドサービス!!! そのうち 170 件は人事サービス関連、110 件はマーケティング関連、76 件はコミュニケーション分野、700 件は財務と CRM に関連しています。シスコは XNUMX の外部クラウドサービス「のみ」を使用しています。したがって、この数字には少し混乱しています。しかし、いずれにせよ、問題は企業側にあるのではなく、クラウドインフラストラクチャを自社のネットワークと同じように監視できる機能を備えたいと考える企業が増加しており、クラウドが非常に積極的に使用され始めているという事実にあります。そしてこの傾向はますます高まっています - によるとアメリカ会計院によると 2023 年までに、米国では 1200 のデータセンターが閉鎖される予定です (6250 はすでに閉鎖されています)。しかし、クラウドへの移行は単に「サーバーを外部プロバイダーに移しましょう」ということではありません。新しい IT アーキテクチャ、新しいソフトウェア、新しいプロセス、新しい制限...これらすべてが、IT だけでなく情報セキュリティの業務にも大きな変化をもたらします。そして、プロバイダーがクラウド自体のセキュリティを確保することに何らかの方法で対処する方法を学んだ場合（幸いなことに、多くの推奨事項があります）、特に SaaS プラットフォームでのクラウド情報セキュリティの監視には重大な困難が伴いますが、これについては後で説明します。

あなたの会社がインフラストラクチャの一部をクラウドに移行したとします...やめてください。この方法ではありません。インフラストラクチャが移転されていて、それをどのように監視するかについて考えているだけでは、すでに負けています。 Amazon、Google、または Microsoft (ただし予約制) でない限り、データやアプリケーションを監視する機能はおそらくあまりありません。ログを扱う機会が与えられると良いでしょう。セキュリティイベントデータが利用可能な場合もありますが、アクセスすることはできません。たとえば、Office 365 です。最も安価な E1 ライセンスを所有している場合、セキュリティイベントはまったく利用できません。 E3 ライセンスを持っている場合、データは 90 日間のみ保存され、E5 ライセンスを持っている場合に限り、ログの期間は 3 年間利用できます (ただし、これには、個別にログを保存する必要性に関連する独自のニュアンスもあります)ログを操作するための多くの機能を Microsoft サポートにリクエストしてください)。ちなみに、E5ライセンスは法人向けExchangeに比べて監視機能がかなり弱いです。同じレベルを達成するには、EXNUMX ライセンスまたは追加の Advanced Compliance ライセンスが必要です。これには、クラウドインフラストラクチャへの移行のための財務モデルに考慮されていない追加の費用が必要になる場合があります。これは、クラウド情報セキュリティの監視に関連する問題が過小評価されている一例にすぎません。この記事では、完全であるふりをすることなく、セキュリティの観点からクラウドプロバイダーを選択する際に考慮すべきいくつかのニュアンスに注意を払いたいと思います。また、記事の最後には、クラウド情報セキュリティの監視の問題が解決されたと考える前に完了する価値のあるチェックリストが示されています。

クラウド環境ではインシデントにつながる典型的な問題がいくつかあり、情報セキュリティサービスが対応する時間がないか、まったく認識できません。

セキュリティログは存在しません。これは、特にクラウドソリューション市場の初心者の間でよく見られる状況です。しかし、すぐにそれらを諦めてはいけません。小規模企業、特に国内企業は顧客の要件に敏感であり、承認された製品のロードマップを変更することで、必要な機能の一部を迅速に実装できます。はい、これは Amazon の GuardDuty や Bitrix の「Proactive Protection」モジュールの類似品ではありませんが、少なくとも何かです。
情報セキュリティ担当者は、ログがどこに保存されているか、またはログにアクセスできないかを知りません。ここでは、クラウドサービスプロバイダーとの交渉を開始する必要があります。おそらく、クライアントが彼にとって重要であると考えれば、クラウドサービスプロバイダーはそのような情報を提供するでしょう。しかし一般に、ログへのアクセスが「特別な決定によって」提供される場合、あまり良いとは言えません。
クラウドプロバイダーがログを持っていることもありますが、提供される監視とイベントの記録は限定的であり、すべてのインシデントを検出するには十分ではありません。たとえば、サイト上の変更のログやユーザー認証試行のログのみを受信できますが、ネットワークトラフィックなどの他のイベントは受信できません。これにより、クラウドインフラストラクチャのハッキングの試みを特徴付けるイベントのレイヤー全体が隠蔽されます。。
ログは存在しますが、ログへのアクセスを自動化するのは難しいため、ログを継続的に監視するのではなく、スケジュールに従って監視する必要があります。また、ログを自動的にダウンロードできない場合、(多くの国内クラウドソリューションプロバイダーと同様に) Excel 形式でログをダウンロードすると、企業の情報セキュリティサービス側がログをいじることに抵抗を感じる可能性さえあります。
ログ監視はありません。これはおそらく、クラウド環境で情報セキュリティインシデントが発生する最も不明瞭な理由です。ログは存在するようで、ログへのアクセスを自動化することも可能ですが、誰もそれをしません。なぜ？

共有クラウドセキュリティの概念

クラウドへの移行は常に、インフラストラクチャの制御を維持したいという欲求と、インフラストラクチャの保守を専門とするクラウドプロバイダーのより専門的な手にインフラストラクチャを移管することとの間のバランスを模索することになります。クラウドセキュリティの分野でも、このバランスを追求する必要があります。さらに、使用されるクラウドサービスの提供モデル (IaaS、PaaS、SaaS) に応じて、このバランスは常に異なります。いずれにせよ、今日のすべてのクラウドプロバイダーは、いわゆる責任の共有と情報セキュリティの共有モデルに従っていることを覚えておく必要があります。クラウドはいくつかのことに対して責任を負いますが、その他のことについてはクライアントが責任を負い、データ、アプリケーション、仮想マシン、その他のリソースをクラウドに配置します。クラウドに移行することで、すべての責任がプロバイダーに移されると期待するのは無謀です。しかし、クラウドに移行するときにすべてのセキュリティを自分で構築するのも賢明ではありません。バランスが必要であり、これは次のような多くの要因によって異なります。 - リスク管理戦略、脅威モデル、クラウドプロバイダーが利用できるセキュリティメカニズム、法律など。

たとえば、クラウドでホストされているデータの分類は常にお客様の責任となります。クラウドプロバイダーや外部サービスプロバイダーは、クラウド内のデータにマークを付けたり、違反を特定したり、法律に違反したデータを削除したり、何らかの方法でデータをマスクしたりするのに役立つツールを提供することしかできません。一方、物理的なセキュリティは常にクラウドプロバイダーの責任であり、クライアントと共有することはできません。しかし、データと物理インフラストラクチャの間にあるすべてのものこそが、この記事の議論の主題です。たとえば、クラウドの可用性はプロバイダーの責任であり、ファイアウォールルールの設定や暗号化の有効化はクライアントの責任です。この記事では、現在ロシアで人気のあるさまざまなクラウドプロバイダーによってどのような情報セキュリティ監視メカニズムが提供されているか、その使用の特徴は何か、また、外部オーバーレイソリューション (Cisco E- mail Security) は、サイバーセキュリティの観点からクラウドの機能を拡張します。場合によっては、特にマルチクラウド戦略に従っている場合は、複数のクラウド環境で外部の情報セキュリティ監視ソリューションを同時に使用するしかありません（Cisco CloudLock や Cisco Stealthwatch Cloud など）。場合によっては、選択した (または押し付けた) クラウドプロバイダーが情報セキュリティ監視機能をまったく提供していないことに気づく場合もあります。これは不快なことですが、このクラウドの使用に伴うリスクのレベルを適切に評価できるため、少なからず不快なことでもあります。

クラウドセキュリティ監視のライフサイクル

使用しているクラウドのセキュリティを監視するには、次の XNUMX つのオプションしかありません。

クラウドプロバイダーが提供するツールに依存する
使用する IaaS、PaaS、または SaaS プラットフォームを監視するサードパーティのソリューションを使用する
独自のクラウド監視インフラストラクチャを構築します (IaaS/PaaS プラットフォームのみ)。

これらのオプションのそれぞれにどのような機能があるかを見てみましょう。ただし、まず、クラウドプラットフォームを監視するときに使用される一般的なフレームワークを理解する必要があります。クラウドにおける情報セキュリティ監視プロセスの 6 つの主要コンポーネントを取り上げます。

インフラの準備。情報セキュリティにとって重要なイベントをストレージに収集するために必要なアプリケーションとインフラストラクチャを決定します。
コレクション。この段階では、セキュリティイベントがさまざまなソースから集約され、その後の処理、保存、分析のために送信されます。
処理。この段階では、その後の分析を容易にするためにデータが変換および強化されます。
ストレージ。このコンポーネントは、収集された処理済みデータと生データの短期および長期の保管を担当します。
分析。この段階では、インシデントを検出し、自動または手動で対応することができます。
報告。この段階は、プロバイダーの変更や情報セキュリティの強化など、特定の意思決定を行う際に役立つ、利害関係者 (経営陣、監査人、クラウドプロバイダー、クライアントなど) 向けの重要な指標を策定するのに役立ちます。

これらのコンポーネントを理解することで、将来的にプロバイダーから何を利用できるか、また自分自身または外部コンサルタントの協力を得て何を行う必要があるかを迅速に決定できるようになります。

組み込みのクラウドサービス

現在の多くのクラウドサービスは情報セキュリティ監視機能を提供していないことはすでに上で書きました。一般に、彼らは情報セキュリティの話題にあまり注意を払っていません。たとえば、インターネット経由で政府機関にレポートを送信するためのロシアで人気のあるサービスの XNUMX つ (名前は特に言及しません)。このサービスのセキュリティに関するセクション全体は、認定された CIPF の使用を中心に展開されます。別の国内電子文書管理クラウドサービスの情報セキュリティ部門も同様だ。公開キー証明書、認定暗号化、Web 脆弱性の排除、DDoS 攻撃からの保護、ファイアウォールの使用、バックアップ、さらには定期的な情報セキュリティ監査についても説明されています。しかし、監視については一言も触れられておらず、このサービスプロバイダーの顧客が関心を持つ可能性のある情報セキュリティイベントにアクセスできる可能性についても言及されていません。

一般に、クラウドプロバイダーが Web サイトやドキュメントで情報セキュリティの問題についてどのように説明しているかを見れば、この問題をどれほど真剣に受け止めているかがわかります。たとえば、「My Office」製品のマニュアルを読むと、セキュリティについてはまったく触れられていませんが、別の製品である「My Office」のマニュアルにはセキュリティに関する記述がありません。 KS3」は、不正アクセスから保護するように設計されており、「My Office.KS17」が実装する FSTEC の 3 次のポイントの通常のリストがありますが、それをどのように実装するか、そして最も重要な方法については説明されていません。これらのメカニズムを企業の情報セキュリティと統合します。おそらくそのようなドキュメントは存在しますが、パブリックドメインの「My Office」Web サイトには見つかりませんでした。もしかしたら私がこの機密情報にアクセスできないだけかもしれませんが?...

Bitrix にとって、状況ははるかに良くなります。このドキュメントでは、イベントログの形式と、興味深いことに、クラウドプラットフォームに対する潜在的な脅威に関連するイベントが含まれる侵入ログについて説明しています。そこから、IP、ユーザーまたはゲスト名、イベントソース、時間、ユーザーエージェント、イベントタイプなどを引き出すことができます。確かに、クラウド自体のコントロールパネルからこれらのイベントを操作することも、MS Excel 形式でデータをアップロードすることもできます。 Bitrix ログを使用した作業を自動化することは現在困難であり、一部の作業 (レポートのアップロードと SIEM へのロード) を手動で行う必要があります。しかし、比較的最近までそのような機会は存在しなかったことを思い出せば、これは大きな進歩です。同時に、多くの外国のクラウドプロバイダーが「初心者向け」の同様の機能を提供していることにも注意してください。コントロールパネルからログを目で見るか、データを自分にアップロードするかのいずれかです（ただし、ほとんどの場合、データは. Excelではなくcsv形式）。

ログなしオプションを考慮せずに、クラウドプロバイダーは通常、セキュリティイベントを監視するための XNUMX つのオプション (ダッシュボード、データアップロード、API アクセス) を提供します。最初の方法は多くの問題を解決するように見えますが、これは完全に真実ではありません。雑誌が複数ある場合、雑誌を表示する画面を切り替える必要があり、全体像が見えなくなります。さらに、クラウドプロバイダーは、セキュリティイベントを関連付けたり、一般にセキュリティの観点から分析したりする機能を提供していない可能性があります (通常、生データを扱うので、それを自分で理解する必要があります)。例外もありますので、それについては後で説明します。最後に、クラウドプロバイダーによってどのようなイベントがどのような形式で記録され、情報セキュリティ監視プロセスにどのように対応しているかを尋ねる価値があります。たとえば、ユーザーとゲストの識別と認証です。同じ Bitrix を使用すると、これらのイベントに基づいて、イベントの日時、ユーザーまたはゲストの名前 (「Web Analytics」モジュールがある場合)、アクセスされたオブジェクト、および Web サイトに典型的なその他の要素を記録できます。。ただし、企業の情報セキュリティサービスでは、ユーザが信頼できるデバイスからクラウドにアクセスしたかどうかに関する情報が必要になる場合があります（たとえば、企業ネットワークでは、このタスクは Cisco ISE によって実装されます）。クラウドサービスのユーザーアカウントが盗まれたかどうかを判断するのに役立つ geo-IP 機能のような単純なタスクについてはどうでしょうか? たとえクラウドプロバイダーがそれを提供したとしても、それだけでは十分ではありません。同じ Cisco CloudLock は地理位置情報を分析するだけでなく、これに機械学習を使用し、各ユーザーの履歴データを分析し、識別と認証の試行におけるさまざまな異常を監視します。同様の機能を備えているのは MS Azure だけです (適切なサブスクリプションを持っている場合)。

もう 2018 つの問題があります。多くのクラウドプロバイダーにとって、情報セキュリティの監視は取り組み始めたばかりの新しいトピックであるため、ソリューションの何かを常に変更しています。今日は API の XNUMX つのバージョンがあり、明日は別のバージョン、明後日は XNUMX 番目のバージョンになります。これに対する準備も必要です。機能についても同様であり、変更される可能性があるため、情報セキュリティ監視システムで考慮する必要があります。たとえば、Amazon は当初、AWS CloudTrail と AWS CloudWatch という個別のクラウドイベント監視サービスを持っていました。その後、情報セキュリティイベントを監視するための別のサービス、AWS GuardDuty が登場しました。しばらくして、Amazon は新しい管理システムである Amazon Security Hub を立ち上げました。これには、GuardDuty、Amazon Inspector、Amazon Macie などから受け取ったデータの分析が含まれています。もう XNUMX つの例は、SIEM との Azure ログ統合ツール - AzLog です。このツールは、XNUMX 年に Microsoft が開発とサポートの終了を発表するまで、多くの SIEM ベンダーによって積極的に使用されていました。そのため、このツールを使用していた多くのクライアントは問題に直面しました (問題がどのように解決されたかについては後で説明します)。

したがって、クラウドプロバイダーが提供するすべての監視機能を注意深く監視してください。または、SOC と監視対象のクラウドの間の仲介者として機能する外部ソリューションプロバイダーに依存します。はい、費用は高くなりますが (常にではありませんが)、すべての責任を他人の肩に押し付けることになります。それともすべてではありませんか?. 共有セキュリティの概念を思い出し、何も変更できないことを理解しましょう。さまざまなクラウドプロバイダーがデータ、アプリケーション、仮想マシン、その他のリソースの情報セキュリティの監視をどのように提供しているかを個別に理解する必要があります。クラウドでホストされます。このパートでは、Amazon が提供するものから始めます。

例：AWSをベースとしたIaaSにおける情報セキュリティ監視

はい、はい、Amazon が最良の例ではないことは理解しています。これはアメリカのサービスであり、過激主義との戦いやロシアで禁止されている情報の拡散の一環としてブロックされる可能性があるためです。ただし、この出版物では、さまざまなクラウドプラットフォームの情報セキュリティ監視機能がどのように異なるのか、また、セキュリティの観点から主要なプロセスをクラウドに転送する際に何に注意すべきなのかを説明したいと思います。そうですね、ロシアのクラウドソリューション開発者の中に、自分にとって役立つことを学べれば、それは素晴らしいことです。

まず最初に言っておきたいのは、アマゾンは難攻不落の要塞ではないということです。彼の依頼人には定期的に様々な事件が起こる。たとえば、198 億 14 万人の有権者の名前、住所、生年月日、電話番号が Deep Root Analytics から盗まれました。イスラエルの企業 Nice Systems は、Verizon 加入者の XNUMX 万件の記録を盗みました。ただし、AWS の組み込み機能を使用すると、幅広いインシデントを検出できます。例えば：

インフラストラクチャへの影響 (DDoS)
ノード侵害 (コマンドインジェクション)
アカウント侵害と不正アクセス
不適切な構成と脆弱性
安全でないインターフェイスと API。

この矛盾は、上記で判明したように、顧客データのセキュリティについては顧客自身が責任を負っているという事実によるものです。そして、もし彼が保護メカニズムをわざわざ有効にせず、監視ツールも有効にしなかった場合、彼はその事件についてメディアか顧客からのみ知ることになるでしょう。

インシデントを特定するには、Amazon が開発したさまざまな監視サービスを幅広く使用できます (ただし、これらは osquery などの外部ツールによって補完されることがよくあります)。そのため、AWS では、管理コンソール、コマンドライン、SDK、またはその他の AWS サービスを通じて実行された方法に関係なく、すべてのユーザーアクションが監視されます。各 AWS アカウントのアクティビティ (ユーザー名、アクション、サービス、アクティビティパラメータ、結果を含む) と API の使用状況のすべての記録は、AWS CloudTrail を通じて利用できます。これらのイベント (AWS IAM コンソールのログインなど) を CloudTrail コンソールから表示したり、Amazon Athena を使用して分析したり、Splunk、AlienVault などの外部ソリューションに「アウトソーシング」したりできます。 AWS CloudTrail ログ自体は AWS S3 バケットに配置されます。

他の 30 つの AWS サービスは、その他の重要な監視機能を多数提供します。まず、Amazon CloudWatch は AWS のリソースとアプリケーションの監視サービスであり、特にクラウド内のさまざまな異常を特定できます。 Amazon Elastic Compute Cloud (サーバー)、Amazon Relational Database Service (データベース)、Amazon Elastic MapReduce (データ分析)、その他 XNUMX の Amazon サービスなど、すべての組み込み AWS サービスは、Amazon CloudWatch を使用してログを保存します。開発者は、Amazon CloudWatch のオープン API を使用して、カスタムアプリケーションやサービスにログ監視機能を追加し、セキュリティコンテキスト内のイベント分析の範囲を拡張できます。

次に、VPC フローログサービスを使用すると、AWS サーバー (外部または内部) およびマイクロサービス間で送受信されるネットワークトラフィックを分析できます。 AWS VPC リソースのいずれかがネットワークと対話すると、VPC フローログは、送信元および宛先のネットワークインターフェイス、IP アドレス、ポート、プロトコル、バイト数、パケット数などのネットワークトラフィックに関する詳細を記録します。見た。ローカルネットワークセキュリティの経験がある人は、これがスレッドに似ていると認識するでしょう。 NetFlow、スイッチ、ルーター、エンタープライズグレードのファイアウォールによって作成できます。これらのログは、ユーザーやアプリケーションのアクションに関するイベントとは異なり、AWS 仮想プライベートクラウド環境でのネットワークインタラクションを見逃さないようにすることもできるため、情報セキュリティ監視の目的にとって重要です。

要約すると、これら XNUMX つの AWS サービス (AWS CloudTrail、Amazon CloudWatch、VPC Flow Logs) を組み合わせることで、アカウントの使用状況、ユーザーの行動、インフラストラクチャ管理、アプリケーションとサービスのアクティビティ、ネットワークアクティビティについての非常に強力な洞察が得られます。たとえば、次の異常を検出するために使用できます。

サイトのスキャン、バックドアの検索、「404 エラー」のバーストによる脆弱性の検索を試みます。
「500 エラー」のバーストによるインジェクション攻撃 (SQL インジェクションなど)。
既知の攻撃ツールには、sqlmap、nikto、w3af、nmap などがあります。ユーザーエージェントフィールドの分析を通じて。

アマゾンウェブサービスは、他の多くの問題を解決できるサイバーセキュリティ目的の他のサービスも開発しました。たとえば、AWS には、ポリシーと構成を監査するための組み込みサービスである AWS Config があります。このサービスは、AWS リソースとその構成の継続的な監査を提供します。簡単な例を見てみましょう。すべてのサーバーでユーザーパスワードが無効になっていて、アクセスが証明書に基づいてのみ可能であることを確認したいとします。 AWS Config を使用すると、すべてのサーバーについてこれを簡単に確認できます。クラウドサーバーに適用できるポリシーは他にもあります。「ポート 22 を使用できるサーバーは存在しない」、「管理者のみがファイアウォールルールを変更できる」、または「ユーザー Ivashko のみが新しいユーザーアカウントを作成でき、彼は火曜日にのみ作成できます。」」 2016 年の夏、AWS Config サービスは、開発されたポリシーの違反の検出を自動化するために拡張されました。 AWS Config Rules は基本的に、使用する Amazon サービスに対する継続的な設定リクエストであり、対応するポリシーに違反した場合にイベントを生成します。たとえば、AWS Config クエリを定期的に実行して仮想サーバー上のすべてのディスクが暗号化されていることを確認する代わりに、AWS Config ルールを使用してサーバーディスクを継続的にチェックし、この条件が満たされていることを確認できます。そして最も重要なことは、この出版物の文脈において、違反は情報セキュリティサービスによって分析できるイベントを生成することです。

AWS には、従来の企業情報セキュリティソリューションと同等のソリューションもあり、分析できる、分析すべきセキュリティイベントも生成されます。

侵入検知 - AWS GuardDuty
情報漏洩管理 - AWS Macie
EDR (クラウド内のエンドポイントについて少し奇妙に話していますが) - AWS Cloudwatch + オープンソース osquery または GRR ソリューション
Netflow 分析 - AWS Cloudwatch + AWS VPC フロー
DNS 分析 - AWS Cloudwatch + AWS Route53
AD - AWS ディレクトリサービス
アカウント管理 - AWS IAM
SSO - AWS SSO
セキュリティ分析 - AWS Inspector
設定管理 - AWS Config
WAF - AWS WAF。

情報セキュリティの観点から役立つ可能性のあるすべての Amazon サービスについては詳しく説明しません。重要なことは、これらすべてが、情報セキュリティのコンテキストで分析できる、また分析すべきイベントを生成する可能性があることを理解することです。この目的のために、Amazon 自体の組み込み機能と外部ソリューション (たとえば、SIEM) の両方を使用します。セキュリティイベントを監視センターに持ち込み、他のクラウドサービスや内部インフラストラクチャ、境界、モバイルデバイスからのイベントとともに分析します。

いずれの場合も、情報セキュリティイベントを提供するデータソースからすべてが始まります。これらのソースには次のものが含まれますが、これらに限定されません。

CloudTrail - API の使用法とユーザーのアクション
Trusted Advisor - ベストプラクティスに対するセキュリティチェック
構成 - アカウントとサービス設定のインベントリと構成
VPC フローログ - 仮想インターフェイスへの接続
IAM - 識別および認証サービス
ELB アクセスログ - ロードバランサー
インスペクター - アプリケーションの脆弱性
S3 - ファイルストレージ
CloudWatch - アプリケーションアクティビティ
SNSは通知サービスです。

Amazon は、自社世代向けにこのような幅広いイベントソースとツールを提供していますが、情報セキュリティの観点から収集したデータを分析する能力は非常に限られています。利用可能なログを独自に調査し、ログ内の侵害の関連する兆候を探す必要があります。 Amazon が最近立ち上げた AWS Security Hub は、AWS のクラウド SIEM となることでこの問題を解決することを目指しています。しかし、これまでのところ、それはまだ旅の始まりにすぎず、動作するソースの数と、Amazon 自体のアーキテクチャとサブスクリプションによって確立されたその他の制限の両方によって制限されています。

例：AzureをベースとしたIaaSにおける情報セキュリティ監視

XNUMX つのクラウドプロバイダー (Amazon、Microsoft、Google) のどれが優れているかについて長い議論をするつもりはありません (特に、それぞれのプロバイダーにはまだ独自の特徴があり、独自の問題を解決するのに適しているためです)。これらのプレーヤーが提供する情報セキュリティ監視機能に焦点を当ててみましょう。 Amazon AWS はこの分野で最初のものの XNUMX つであるため、情報セキュリティ機能の点で最も進歩していることを認めなければなりません (ただし、使いにくいことは多くの人が認めています)。しかし、これは Microsoft と Google が提供する機会を無視するという意味ではありません。

Microsoft 製品は常にその「オープン性」によって際立ってきましたが、Azure でも状況は同様です。たとえば、AWS や GCP が常に「禁止されているものは禁止される」という概念で進められているとしたら、Azure は真逆のアプローチをとります。たとえば、クラウド内に仮想ネットワークを作成し、その中に仮想マシンを作成する場合、デフォルトですべてのポートとプロトコルがオープンされ、許可されます。したがって、Microsoft のクラウドでのアクセス制御システムの初期セットアップには、もう少し労力を費やす必要があります。また、これにより、Azure クラウドでのアクティビティの監視に関して、より厳しい要件が課せられます。

AWS には、仮想リソースを監視するときに、仮想リソースが異なるリージョンにある場合、すべてのイベントとその統合分析を組み合わせることは困難であり、これを排除するには、次のようなさまざまなトリックに頼る必要があるという特性があります。リージョン間でイベントを転送する AWS Lambda 用の独自のコードを作成します。 Azure にはこの問題はありません。Azure のアクティビティログメカニズムは、組織全体のすべてのアクティビティを制限なく追跡します。同じことが AWS Security Hub にも当てはまります。AWS Security Hub は、多くのセキュリティ機能を XNUMX つのセキュリティセンター内に統合するために Amazon によって最近開発されましたが、その地域内のみであり、ロシアには関係ありません。 Azure には、地域の制限に縛られない独自のセキュリティセンターがあり、クラウドプラットフォームのすべてのセキュリティ機能へのアクセスを提供します。さらに、さまざまなローカルチームに対して、チームが管理するセキュリティイベントなど、独自の保護機能セットを提供できます。 AWS Security Hub は、Azure Security Center に似たものになる途上にあります。ただし、これには問題を追加する価値があります。AWS で前述した多くの機能を Azure から絞り出すことができますが、これは Azure AD、Azure Monitor、および Azure Security Center に対してのみ行われるのが最も便利です。セキュリティイベント分析を含む他のすべての Azure セキュリティメカニズムは、まだ最も便利な方法で管理されていません。この問題は、すべての Microsoft Azure サービスに浸透している API によって部分的に解決されますが、これには、クラウドを SOC と統合するための追加の努力と、資格のあるスペシャリストの存在が必要になります (実際、クラウドと連携する他の SIEM と同様)。 API)。後で説明する一部の SIEM はすでに Azure をサポートしており、監視タスクを自動化できますが、独自の難点もあります。すべての SIEM が Azure のすべてのログを収集できるわけではありません。

Azure でのイベントの収集と監視は、Microsoft クラウドとそのリソース (Git リポジトリ、コンテナー、仮想マシン、アプリケーションなど) 内のデータを収集、保存、分析するための主要なツールである Azure Monitor サービスを使用して提供されます。 Azure Monitor によって収集されるすべてのデータは、リアルタイムで収集され、Azure クラウドの主要なパフォーマンス指標を記述するメトリックと、Azure リソースとサービスのアクティビティの特定の側面を特徴付けるレコードに編成されたデータを含むログの XNUMX つのカテゴリに分類されます。さらに、データコレクター API を使用すると、Azure Monitor サービスは任意の REST ソースからデータを収集し、独自の監視シナリオを構築できます。

Azure が提供し、Azure Portal、CLI、PowerShell、または REST API を介してアクセスできる (一部は Azure Monitor/Insight API を介してのみ) いくつかのセキュリティイベントソースを次に示します。

アクティビティログ - このログは、クラウドリソースに対する書き込み操作 (PUT、POST、DELETE) に関する「誰が」、「何を」、「いつ」という古典的な質問に答えます。読み取りアクセス (GET) に関連するイベントは、他の多くのイベントと同様、このログには含まれません。
診断ログ - サブスクリプションに含まれる特定のリソースの操作に関するデータが含まれます。
Azure AD レポート - グループとユーザーの管理に関連するユーザーアクティビティとシステムアクティビティの両方が含まれます。
Windows イベントログと Linux Syslog - クラウドでホストされている仮想マシンからのイベントが含まれます。
メトリクス - クラウドサービスとリソースのパフォーマンスと健全性ステータスに関するテレメトリが含まれます。 30分ごとに測定し、保存します。 XNUMX日以内に。
ネットワークセキュリティグループフローログ - Network Watcher サービスおよびネットワークレベルでのリソース監視を使用して収集されたネットワークセキュリティイベントに関するデータが含まれます。
ストレージログ - ストレージ設備へのアクセスに関連するイベントが含まれます。

監視には、外部 SIEM または組み込みの Azure Monitor とその拡張機能を使用できます。情報セキュリティイベント管理システムについては後ほど説明しますが、ここでは、セキュリティの観点から Azure 自体がデータ分析に何を提供してくれるかを見てみましょう。 Azure Monitor のセキュリティ関連のすべてのメイン画面は、Log Analytics のセキュリティと監査ダッシュボードです (無料版では、わずか 5 週間の限られた量のイベントストレージがサポートされます)。このダッシュボードは、使用しているクラウド環境で何が起こっているかの概要統計を視覚化する XNUMX つの主要な領域に分かれています。

セキュリティドメイン - 情報セキュリティに関連する主要な定量的指標 - インシデントの数、侵害されたノードの数、パッチが適用されていないノード、ネットワークセキュリティイベントなど。
注目すべき問題 - 進行中の情報セキュリティ問題の数と重要性を表示します。
検出 - あなたに対して使用された攻撃のパターンを表示します
脅威インテリジェンス - 攻撃している外部ノードの地理情報を表示します。
一般的なセキュリティクエリ - 情報セキュリティをより適切に監視するのに役立つ一般的なクエリ。

Azure Monitor 拡張機能には、Azure Key Vault (クラウド内の暗号キーの保護)、Malware Assessment (仮想マシン上の悪意のあるコードに対する保護の分析)、Azure Application Gateway Analytics (特に、クラウドファイアウォールログの分析) などが含まれます。。イベントを処理するための特定のルールが強化されたこれらのツールを使用すると、セキュリティを含むクラウドサービスのアクティビティのさまざまな側面を視覚化し、運用からの特定の逸脱を特定できます。ただし、よくあることですが、追加機能には対応する有料サブスクリプションが必要であり、対応する財務投資が必要となるため、事前に計画する必要があります。

Azure には、Azure AD、Azure Monitor、および Azure Security Center に統合された脅威監視機能が多数組み込まれています。その中には、たとえば、仮想マシンと既知の悪意のある IP との相互作用の検出 (Microsoft の脅威インテリジェンスサービスとの統合の存在による)、クラウドでホストされている仮想マシンからのアラームの受信によるクラウドインフラストラクチャ内のマルウェアの検出、パスワードなどが含まれます。仮想マシンに対する推測攻撃、ユーザー識別システムの構成の脆弱性、アノニマイザーまたは感染したノードからのシステムへのログイン、アカウント漏洩、通常とは異なる場所からのシステムへのログインなどです。現在の Azure は、収集された情報セキュリティイベントを強化する組み込みの脅威インテリジェンス機能を提供する数少ないクラウドプロバイダーの XNUMX つです。

前述したように、セキュリティ機能とその結果生成されるセキュリティイベントは、すべてのユーザーが平等に利用できるわけではありませんが、情報セキュリティ監視に適切なイベントを生成する、必要な機能を含む特定のサブスクリプションが必要です。たとえば、前の段落で説明したアカウントの異常を監視する機能の一部は、Azure AD サービスの P2 プレミアムライセンスでのみ利用できます。これがないと、AWS の場合と同様に、収集されたセキュリティイベントを「手動」で分析する必要があります。また、Azure AD ライセンスの種類によっては、すべてのイベントを分析に利用できるわけではありません。

Azure portal では、関心のあるログの検索クエリを管理したり、主要な情報セキュリティ指標を視覚化するためのダッシュボードを設定したりできます。さらに、そこで Azure Monitor 拡張機能を選択することもできます。これにより、Azure Monitor ログの機能を拡張し、セキュリティの観点からイベントをより深く分析できます。

ログを操作する機能だけでなく、情報セキュリティポリシー管理を含む Azure クラウドプラットフォームの包括的なセキュリティセンターが必要な場合は、Azure Security Center と連携する必要性について話すことができます。Azure Security Center の便利な機能のほとんどは、たとえば、脅威の検出、Azure 外部の監視、コンプライアンス評価などは、ある程度のお金を支払えば利用できます。 (無料版では、セキュリティ評価と、特定された問題を排除するための推奨事項にのみアクセスできます)。すべてのセキュリティ問題を 365 か所に統合します。実際、Azure Monitor が提供するよりも高いレベルの情報セキュリティについて話すことができます。この場合、クラウドファクトリ全体で収集されたデータは、Azure、Office XNUMX、Microsoft CRM online、Microsoft Dynamics AX などの多くのソースを使用して強化されるためです。、outlook .com、MSN.com、Microsoft Digital Crimes Unit (DCU)、および Microsoft Security Response Center (MSRC) には、さまざまな高度な機械学習および行動分析アルゴリズムが重ねられており、最終的には脅威の検出と対応の効率が向上します。。

Azure にも独自の SIEM があり、2019 年の初めに登場しました。これは Azure Sentinel で、Azure Monitor からのデータに依存しており、統合することもできます。外部セキュリティソリューション (NGFW や WAF など) のリストは増え続けています。さらに、Microsoft Graph Security API の統合により、独自の脅威インテリジェンスフィードを Sentinel に接続できるようになり、Azure クラウド内のインシデントを分析する機能が強化されます。 Azure Sentinel は、クラウドプロバイダーから登場した最初の「ネイティブ」 SIEM であると主張できます (AWS などのクラウドでホストできる同じ Splunk や ELK は、従来のクラウドサービスプロバイダーによってまだ開発されていません)。 Azure Sentinel と Security Center は、Azure クラウドの SOC と呼ばれ、インフラストラクチャがなくなり、すべてのコンピューティングリソースをクラウドに転送した場合、(特定の条件付きで) それらに限定される可能性があり、それが Microsoft クラウド Azure になります。

ただし、情報セキュリティを監視し、このプロセスを他のセキュリティイベントソース (クラウドと内部の両方) と統合するという目的には、Azure の組み込み機能 (Sentinel のサブスクリプションを持っている場合でも) では不十分な場合が多いため、収集したデータを外部システム (SIEM を含む場合がある) にエクスポートする必要があります。これは、API と特別な拡張機能の両方を使用して行われます。これらの拡張機能は現在、Splunk (Splunk 用 Azure Monitor アドオン)、IBM QRadar (Microsoft Azure DSM)、SumoLogic、ArcSight、ELK の SIEM でのみ正式に利用可能です。最近まで、このような SIEM はさらに多くありましたが、1 年 2019 月 XNUMX 日から、Microsoft は Azure Log Integration Tool (AzLog) のサポートを停止しました。これは、Azure の存在黎明期であり、ログの操作に関する通常の標準化がなかったためです (Azure Monitor はまだ存在していませんでした) により、外部 SIEM を Microsoft クラウドと簡単に統合できるようになりました。現在では状況が変わり、Microsoft は他の SIEM の主要な統合ツールとして Azure Event Hub プラットフォームを推奨しています。多くの企業はすでにこのような統合を実装していますが、すべての Azure ログがキャプチャされるわけではなく、一部のみがキャプチャされる可能性があることに注意してください (SIEM のドキュメントを参照してください)。

Azure についての簡単な説明の締めくくりとして、このクラウドサービスに関する一般的な推奨事項を述べたいと思います。Azure の情報セキュリティ監視機能について何かを言う前に、それらを非常に慎重に構成し、ドキュメントに記載されているとおりに機能することをテストする必要があります。コンサルタントが Microsoft に語ったとおりです (また、コンサルタントは Azure 関数の機能について異なる見解を持っている可能性があります)。財務リソースがあれば、情報セキュリティ監視の観点から Azure から多くの有益な情報を絞り出すことができます。 AWS の場合のようにリソースが限られている場合は、自分の力と Azure Monitor が提供する生データのみに頼る必要があります。また、多くの監視機能には費用がかかるため、事前に価格ポリシーをよく理解しておくことをお勧めします。たとえば、無料で、顧客あたり最大 31 GB まで 5 日間のデータを保存できます。これらの値を超えると、追加のお金を支払う必要があります (顧客から追加の 2 GB を保存する場合は約 0,1 ドル以上、1 ドル以上の場合は XNUMX ドル)追加月ごとに XNUMX GB を保存します)。アプリケーションテレメトリとメトリクスの操作には、アラートと通知の操作だけでなく、追加の資金も必要になる場合があります (一定の制限は無料で利用できますが、ニーズには十分ではない場合があります)。

例：Google Cloud PlatformをベースとしたIaaSにおける情報セキュリティ監視

Google Cloud Platform は AWS や Azure と比べるとまだ若いように見えますが、これは部分的には良いことです。 AWS とは異なり、セキュリティ機能を含む機能を徐々に強化しましたが、一元化に問題がありました。 GCP は、Azure と同様に一元管理がはるかに優れているため、企業全体でのエラーと実装時間が削減されます。セキュリティの観点から見ると、奇妙なことに、GCP は AWS と Azure の間に位置します。彼は組織全体に対する単一のイベント登録も行っていますが、それは不完全です。一部の機能はまだベータ版ですが、徐々にこの欠陥は解消され、GCP は情報セキュリティ監視の点でより成熟したプラットフォームになるはずです。

GCP でイベントをログに記録するための主なツールは Stackdriver Logging (Azure Monitor と同様) です。これを使用すると、クラウドインフラストラクチャ全体 (AWS からだけでなく) でイベントを収集できます。 GCP のセキュリティの観点から、各組織、プロジェクト、またはフォルダーには次の XNUMX つのログがあります。

管理アクティビティ - 仮想マシンの作成、アクセス権の変更など、管理アクセスに関連するすべてのイベントが含まれます。このログはユーザーの希望に関係なく常に書き込まれ、データは 400 日間保存されます。
データアクセス - クラウドユーザーによるデータの操作 (作成、変更、読み取りなど) に関連するすべてのイベントが含まれます。このログの量は急速に増大するため、デフォルトではこのログは書き込まれません。このため、賞味期限は30日しかありません。また、本誌にすべてが書かれているわけではありません。たとえば、すべてのユーザーがパブリックにアクセスできるリソース、または GCP にログインせずにアクセスできるリソースに関連するイベントは、GCP に書き込まれません。
システムイベント - ユーザーに関係のないシステムイベント、またはクラウドリソースの構成を変更する管理者のアクションが含まれます。常に書き込まれ、400 日間保存されます。
アクセスの透明性は、職務の一環としてインフラストラクチャにアクセスする Google 従業員のすべてのアクション (ただし、すべての GCP サービスについてはまだ対象ではありません) をキャプチャするログのユニークな例です。このログは 400 日間保存され、すべての GCP クライアントが利用できるわけではありませんが、いくつかの条件（ゴールドまたはプラチナレベルのサポート、または企業サポートの一環としての特定の種類の 4 つの役割の存在）が満たされた場合にのみ利用できます。同様の機能は、たとえば Office 365 - Lockbox でも利用できます。

ログの例: アクセスの透明性

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

これらのログへのアクセスは、ログビューアインターフェイス、API、Google Cloud SDK、または対象プロジェクトのアクティビティページなど、いくつかの方法 (前述の Azure および AWS とほぼ同じ方法) で可能です。イベントに興味がある。同様に、追加の分析のために外部ソリューションにエクスポートできます。後者は、ログを BigQuery または Cloud Pub/Sub ストレージにエクスポートすることで実行されます。

Stackdriver Logging に加えて、GCP プラットフォームは Stackdriver Monitoring 機能も提供します。これにより、クラウドサービスとアプリケーションの主要な指標 (パフォーマンス、MTBF、全体的な健全性など) を監視できます。処理および視覚化されたデータにより、セキュリティのコンテキストを含め、クラウドインフラストラクチャの問題を見つけやすくなります。ただし、情報セキュリティの観点からは、この機能はあまり豊富ではないことに注意してください。現在、GCP には同じ AWS GuardDuty に相当するものがなく、登録されているすべてのイベントの中から悪質なイベントを特定できないためです (Google はイベント脅威検出を開発しました。ただし、まだベータ版で開発中のため、その有用性について話すのは時期尚早です)。 Stackdriver Monitoring は、異常を検出するシステムとして使用でき、異常が発生した原因を調査するために調査されます。しかし、市場に GCP 情報セキュリティの分野で資格のある人材が不足していることを考えると、この課題は現時点では困難であるように見えます。

GCP クラウド内で使用でき、AWS が提供するものと同様の情報セキュリティモジュールのリストをいくつか提供することも価値があります。

Cloud Security Command Center は、AWS Security Hub および Azure Security Center に似ています。
クラウド DLP - 90 を超える事前定義された分類ポリシーを使用して、クラウドでホストされているデータを自動的に検出および編集 (マスキングなど) します。
Cloud Scanner は、App Engine、Compute Engine、Google Kubernetes の既知の脆弱性 (XSS、Flash Injection、パッチが適用されていないライブラリなど) を検出するスキャナです。
Cloud IAM - すべての GCP リソースへのアクセスを制御します。
Cloud Identity - GCP ユーザー、デバイス、アプリケーションのアカウントを単一のコンソールから管理します。
クラウド HSM - 暗号キーの保護。
Cloud Key Management Service - GCP での暗号鍵の管理。
VPC Service Control - GCP リソースの周囲に安全な境界を作成し、リソースを漏洩から保護します。
Titan セキュリティキー - フィッシングからの保護。

これらのモジュールの多くは、分析のために BigQuery ストレージに送信したり、SIEM などの他のシステムにエクスポートしたりできるセキュリティイベントを生成します。前述したように、GCP は積極的に開発中のプラットフォームであり、Google は現在、そのプラットフォーム用に多数の新しい情報セキュリティモジュールを開発しています。その中には、Stackdriver ログをスキャンして不正なアクティビティの痕跡を探す Event Threat Detection (現在ベータ版で利用可能) (AWS の GuardDuty に類似) や、インテリジェントなポリシーを開発できるようにする Policy Intelligence (アルファ版で利用可能) があります。 GCP リソースへのアクセス。

一般的なクラウドプラットフォームに組み込まれている監視機能について簡単に概要を説明しました。しかし、「生の」IaaS プロバイダーログを処理できる専門家はいますか (誰もが AWS、Azure、または Google の高度な機能を購入する準備ができているわけではありません)。さらに、多くの人は「信頼するが検証せよ」という格言をよく知っていますが、これはセキュリティの分野ではこれまで以上に真実です。情報セキュリティイベントを送信するクラウドプロバイダーの組み込み機能をどの程度信頼しますか? 彼らは情報セキュリティにどの程度重点を置いていますか?

組み込みのクラウドセキュリティを補完できるオーバーレイクラウドインフラストラクチャ監視ソリューションを検討する価値がある場合もあれば、そのようなソリューションがクラウドでホストされているデータとアプリケーションのセキュリティについて洞察を得る唯一の選択肢である場合もあります。さらに、さまざまなクラウドプロバイダーのさまざまなクラウドサービスによって生成される必要なログを分析するタスクをすべて引き受けるので、単純に便利です。このようなオーバーレイソリューションの例としては、Cisco Stealthwatch Cloud があります。これは、Amazon AWS、Microsoft Azure、Google Cloud Platform だけでなく、プライベートクラウドなどのクラウド環境における情報セキュリティの異常を監視するという XNUMX つのタスクに重点を置いています。

例: Stealthwatch Cloud を使用した情報セキュリティ監視

AWS は柔軟なコンピューティングプラットフォームを提供しますが、この柔軟性により、企業はセキュリティ問題につながる間違いを犯しやすくなります。そして、共有情報セキュリティモデルはこれに貢献するだけです。未知の脆弱性（既知の脆弱性は、AWS Inspector や GCP Cloud Scanner などで対処できる）、脆弱なパスワード、不正な構成、内部関係者などを抱えたクラウドでソフトウェアを実行している。これらすべてはクラウドリソースの動作に反映されており、情報セキュリティの監視および攻撃検出システムである Cisco Stealthwatch Cloud によって監視できます。パブリッククラウドとプライベートクラウド。

Cisco Stealthwatch Cloud の重要な機能の XNUMX つは、エンティティをモデル化する機能です。これを使用すると、各クラウドリソース (AWS、Azure、GCP、またはその他のものであるかどうかは関係ありません) のソフトウェアモデル (つまり、ほぼリアルタイムのシミュレーション) を作成できます。これらには、サーバーとユーザーに加えて、セキュリティグループや自動スケールグループなど、クラウド環境に固有のリソースタイプが含まれる場合があります。これらのモデルは、クラウドサービスによって提供される構造化データストリームを入力として使用します。たとえば、AWS の場合、これらは VPC フローログ、AWS CloudTrail、AWS CloudWatch、AWS Config、AWS Inspector、AWS Lambda、AWS IAM になります。エンティティモデリングは、リソースの役割と動作を自動的に検出します (すべてのクラウドアクティビティのプロファイリングについて話すことができます)。これらの役割には、Android または Apple モバイルデバイス、Citrix PVS サーバー、RDP サーバー、メールゲートウェイ、VoIP クライアント、ターミナルサーバー、ドメインコントローラーなどが含まれます。その後、ユーザーの行動を継続的に監視して、危険な行動や安全を脅かす行動がいつ発生したかを判断します。パスワード推測、DDoS 攻撃、データ漏洩、違法なリモートアクセス、悪意のあるコードのアクティビティ、脆弱性スキャン、その他の脅威を特定できます。たとえば、組織にとって典型的ではない国 (韓国) から SSH 経由で Kubernetes クラスターへのリモートアクセス試行を検出すると、次のようになります。

そして、これまで交流がなかった国への Postgress データベースからの情報漏洩疑惑は次のようなものです。

最後に、中国とインドネシアからの外部リモートデバイスからの SSH 試行の失敗例は次のようになります。

または、ポリシーにより、VPC 内のサーバーインスタンスがリモートログイン宛先にならないとします。さらに、ファイアウォールルールポリシーの誤った変更により、このコンピュータでリモートログオンが発生したと仮定します。エンティティモデリング機能は、このアクティビティ (「異常なリモートアクセス」) をほぼリアルタイムで検出して報告し、特定の AWS CloudTrail、Azure Monitor、または GCP Stackdriver Logging API 呼び出し (ユーザー名、日付と時刻などの詳細を含む) を示します。 ).これが ITU ルールの変更を促しました。そして、この情報は分析のために SIEM に送信されます。

Cisco Stealthwatch Cloud でサポートされるクラウド環境には、同様の機能が実装されています。

エンティティモデリングは、人、プロセス、テクノロジーに関するこれまで知られていなかった問題を明らかにできる、セキュリティ自動化のユニークな形式です。たとえば、次のようなセキュリティ上の問題を検出できます。

私たちが使用しているソフトウェアのバックドアを誰かが発見したのでしょうか?
クラウド内にサードパーティのソフトウェアまたはデバイスはありますか?
許可されたユーザーが権限を乱用していませんか?
リモートアクセスやその他の意図しないリソースの使用を許可する構成エラーはありましたか?
サーバーからのデータ漏洩はありますか?
誰かが特殊な地理的場所から私たちに接続しようとしたのでしょうか?
私たちのクラウドは悪意のあるコードに感染していますか?

検出された情報セキュリティイベントは、対応するチケットの形式で Slack、Cisco Spark、PagerDuty インシデント管理システムに送信できるほか、Splunk や ELK などのさまざまな SIEM にも送信できます。要約すると、会社がマルチクラウド戦略を採用しており、上記の情報セキュリティモニタリング機能を XNUMX つのクラウドプロバイダーに限定していない場合、統合された一連のモニタリングを実現するには Cisco Stealthwatch Cloud を使用することが良い選択肢であると言えます。主要なクラウドプレーヤー (Amazon、Microsoft、Google) の機能。最も興味深いのは、Stealthwatch Cloud と AWS、Azure、または GCP の情報セキュリティ監視用のアドバンストライセンスの価格を比較すると、Cisco ソリューションの方が Amazon や Microsoft の組み込み機能よりもさらに安価であることが判明する可能性があることです。そしてGoogleのソリューション。逆説的ですが、本当です。使用するクラウドとその機能が増えるほど、統合ソリューションの利点がより明らかになります。

さらに、Stealthwatch Cloud は、たとえば、Kubernetes コンテナに基づいて、またはネットワーク機器 (国産であっても) のミラーリングを通じて受信した Netflow フローやネットワークトラフィック、AD データ、DNS サーバーなどを監視することによって、組織内に展開されているプライベートクラウドを監視できます。このすべてのデータは、世界最大のサイバーセキュリティ脅威研究者の非政府グループである Cisco Talos によって収集された脅威インテリジェンス情報によって強化されます。

これにより、会社が使用するパブリッククラウドとハイブリッドクラウドの両方に統合監視システムを実装できます。収集された情報は、Stealthwatch Cloud の組み込み機能を使用して分析したり、SIEM に送信したりできます (Splunk、ELK、SumoLogic およびその他のいくつかがデフォルトでサポートされています)。

これで、記事の最初の部分を完了します。この記事では、IaaS/PaaS プラットフォームの情報セキュリティを監視するための組み込みおよび外部ツールをレビューしました。これにより、クラウド環境で発生するインシデントを迅速に検出して対応できるようになります。私たちの企業が選んだのです。第 XNUMX 部では、トピックを継続し、Salesforce と Dropbox の例を使用して SaaS プラットフォームを監視するためのオプションを検討します。また、さまざまなクラウドプロバイダー向けに統合された情報セキュリティ監視システムを作成することで、すべてを要約してまとめることも試みます。

出所： habr.com

クラウドセキュリティ監視