- ライター：千葉 豪
- 2009年ネットワンシステムズに入社し、IaaS(Infrastructure as a Service) を始めとしたクラウド基盤技術および管理製品を担当。現在はコンテナ技術を中心とした社内開発基盤・解析基盤の構築・運用や関連した自動化技術、監視製品などの技術検証を行っている。
前半のブログでは「インフラコード化の向こう側へ-米国先進企業が挑戦し始めたポリシーのコード化」と題してこれまで ONUG が歩んできた10年の足並みと、本年より始まった Phase4 のメッセージである「Operationalized Multi-Cloud」および関連する Working Group として新たに創設された Policy as a Code WG についてご紹介しました。
後半となる本ブログでは ONUG Spring で紹介された CSNF(Cloud Security Notification Framework) の技術的側面での紹介と ONUG におけるネットワンシステムズの取り組みについて紹介したいと思います。
CSNF(Cloud Security Notification Framework) とは
CSNF が最初に紹介されたのはちょうど1年前となる ONUG Fall 2021 でのことであり、マルチクラウドが当たり前となった現在でもまだクラウド間の API やメッセージの仕様等には互換性が無く、「Cloud Sprawl (クラウドの無秩序)」を引き起こす要素の1つであると述べられています。
そのような課題に取り組むため ONUG では ONUG Collaborative WG と呼ばれるワーキンググループが形成されており Microsoft, Google, IBM, Oracle といった主要なクラウドプロバイダーや FedEx, Goldman Sachs といった Fortune 100 に名を連ねるユーザー企業が参画しています。
その中でセキュリティアラートの標準化に関するフレームワークとして定義されたのが CSNF となります。
ONUG Spring 2022 では具体的な実装例として Birthday Cake と呼ばれる初期バージョンがリリースされ GitHub 上で公開されています。
本リリースでは以下のようなシナリオでセキュリティイベントの処理を行っています。
- Knative の Source により Apache Kafka, 各種クラウドの PubSub サービス、 Queue サービスなど様々なデータソースからセキュリティイベントを収集
- TriggerMesh の持つ Transformation 機能 により異なるフォーマットのセキュリティイベントを CSNF の標準フォーマットに変換
- 標準化されたイベントは SIEM/SOAR プラットフォームに格納され、イベントの分析またはイベント内容毎のプレイブック実行する準備が完了する
- NIST, MITRE ATT&CK などの外部フレームワークに適用するため CSNF フォーマットを “デコレーション” と呼ばれる処理により拡張
- 必用に応じてネットワーク自動化ソリューションを提供する Gluware に対しイベントを送信し、インシデントに対し修復処理を実行
このように CSNF を用いた初期実装では単純にセキュリティイベントの標準フォーマット化だけではなく、それを利用した分析・自動修復といった NIST のインシデント対応のライフサイクル に即したアーキテクチャとなっています。
ネットワンシステムズの取り組み
このようなフレームワークが提唱された背景には前述した各クラウド間の API 仕様やメッセージの非互換性といった点が挙げられますが、そもそもとしてエンタープライズ企業において複数のクラウドサービスを利用するのが当たり前になってきていることに起因します。
しかしながら、マルチクラウド環境の運用において一貫したセキュリテイポリシーを適用しようとすると以下のような課題に直面します。
・サービス・ベンダー毎に異なる管理アプローチを取る必要がある
・個々のサービス毎にセキュリティイベントのフォーマットが異なる
・様々なデバイス・アプリケーション・利用拠点から構成され従来より管理するべきイベントログの量が増大している
そこでネットワンシステムズでは前述の CSNF のアプローチとベンダーソリューションを組み合わせてベンダー独自のサービスのセキュリティイベントを CSNF フォーマットに変換しログ分析基盤を活用した分析処理を実現しました。
本 PoC では各サービスからのイベントをスクリプトや Fluentd のようなデータシッパーを用いて Apache Kafka の 商用サポート版である Confluent Platform に対して格納していきます。
その後、Knative をベースとした iPaaS ソリューションを提供する TriggerMesh を用い Confluent Platform 内に格納された各イベントメッセージを順次 CSNF フォーマットに変換しログ分析基盤に送信しています。
CSNF フォーマット例
{
"event": {
"name": "SUSPICIOUS_IP_ACTIVITY",
"severity": "CRITICAL",
"shortDescription": "User logged in from a known list of malicious IP blocks which can be a potential threat.",
"startTime": "2022-04-06T18:01:56.498Z",
"status": "OPEN"
},
"provider": {
"accountId": "ocid1.tenancy.oc1..bbbbbbb4yalk3rotsz2d5enoxul4q5mldkbz562dcehkqjpdqe4apvlcxpq"
},
"providerId": "martian@mars.planet",
"providerType": "CSP",
"resource": {
"identifier": "ocid1.user.oc1..bbbbbbbaxqn3hcnoplysuobgwfrlu5urafipjglavxgi5sq4aqyx3c5emt4q",
"name": "martian@mars.planet",
"region": "us-ashburn-1",
"type": "User",
"zone": "cgdemo"
},
"source": {
"sourceId": "none",
"sourceName": "Cloud Guard"
}
}
Confluent Platform や TriggerMesh といったソリューションでは内部のメッセージのやりとりに Apache Kafka のようなメッセージキューを利用しており、メッセージを非同期に処理できる、イベントドリブンでの処理を実行できるといったメリットがあるため大量のイベント処理に適しています。
また、CSNF のような標準フォーマットを利用することでセキュリティインシデントに対しての対応の自動化や分析基盤での傾向分析など複数サービスを連携させる際のパラメーターの受け渡しがスムーズになります。
まとめ
本記事では ONUG で提唱されている CSNF の技術的側面でのご紹介と、CSNF を利用したネットワンシステムズの取り組みを紹介しました。 CSNF 自体はまだ初期リリース段階ですがマルチクラウドの利用がさらに拡大すると管理対象も増大しセキュリティ観点でどのようにガバナンスを効かせるかは課題になることは自明でしょう。
前編で取り上げた Policy as Code の考え方はインフラの設計・開発段階でセキュリティポリシーを管理するというシフトレフトアプローチですが、運用段階におけるセキュリティイベントは CSNF のような標準フレームワークを活用することで自動化、分析を最適化するといったことも重要となるでしょう。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
