サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来

サイバー攻撃を想定した
クラウドネイティブセキュリティガイドラインと
CNAPP 及び Security Observability の
未来
佐古伸晃
2022年08月05日
株式会社野村総合研究所
品質監理本部
情報セキュリティ部
吉江瞬
NRIセキュアテクノロジーズ株式会社
マネージドセキュリティサービス開発本部
MSS技術開発部

View Slide

1
Copyright
（C）Nomura Research Institute, Ltd. NRI SecureTechnologies, Ltd. All rights reserved.
はじめに
01
サイバー攻撃とクラウドネイティブセキュリティ
02
クラウドネイティブセキュリティガイドライン
03
CNAPPとSecurity Observability
04
まとめ
05

View Slide

2
Copyright
自己紹介(佐古伸晃)
サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来
◼野村総合研究所(NRI) 情報セキュリティ部佐古伸晃(SAKO Nobuaki)
⚫ オフィスセキュリティ担当グループマネージャー
⚫ OA環境／社内NWのセキュリティ対策・審査、委託先管理
⚫ 外部クラウドサービスを利用する際のセキュリティ対策・審査
◼業務経歴
⚫ 金融・通信系バックエンドエンジニア→セールス→セキュリティ
⚫ クラウドサービス・クラウドネイティブ関連技術をいかに安全に使うか社内向けガイドライン策定
• 共通ガイドライン：IaaS / PaaS / SaaS 全般
• 個別ガイドライン：AWS / Azure / Google Cloud (GCP) / OCI / Alibaba Cloud 向けの詳細版
• Docker / Kubernetes
• バージョン管理(GitHubなど)
◼好きなクラウドネイティブ技術
⚫ DevSecOps、低レイヤーなもの

View Slide

3
Copyright
自己紹介(吉江瞬)
◼NRIセキュアテクノロジーズ MSS技術開発部吉江瞬(YOSHIE Shun)
⚫ セキュリティコンサルタント/エンジニア
⚫ マネージドセキュリティサービスのサービス開発
◼業務経歴
⚫ マネージドセキュリティサービス運用保守
⚫ クラウドセキュリティ監査
⚫ クラウド向けサービス開発
◼好きなクラウドネイティブ技術
⚫ オブザーバビリティ
◼コミュニティ
⚫ Security-JAWS 運営
⚫ JAWS-UG 東京支部運営

View Slide

4
Copyright
はじめに
01
02
03
04
まとめ
05

View Slide

5
Copyright
そもそもセキュリティとは
◼セキュリティ【security】
• 個人の安全、建物・施設の防犯、国家の安全保証、財産の担保・有価証券など、価値ある資産を守ること
• 情報への第三者の侵入、攻撃、持出、改竄といった不正利用から阻止し、機密性や完全性を保持すること
◼情報セキュリティ【Information Security】の特性
• 機密性 (Confidentiality) ：許可されたものだけがアクセスできること、盗聴されないこと
• 完全性 (Integrity) ：正しい状態で保持されていること、改竄されないこと
• 可用性 (Availability) ：いつでも安全にアクセスできること、バックアップ手段があること
• 真正性 (Authenticity) ：対象が本当にその人・ものであること、認証すること
• 責任追跡性 (Accountability) ：起きたことや原因を追跡できること、ロギングすること
• 否認防止 (Non-Repudiation) ：後からなかったことにはできないこと、署名などで保護すること
• 信頼性 (Reliability) ：安定して期待される役割を果たすこと、冗長化すること
◼脅威を想定し、脆弱性があることを前提に、セキュリティ対策を考える

View Slide

6
Copyright
想定される脅威：サイバー攻撃の傾向を知る
◼OWASP (Open Web Application Security Project) Top 10
⚫ Webアプリケーションのセキュリティ向上を目的とした非営利団体が公開する、最も重大な10のリスク
➢ 定期的に更新され、直近のセキュリティリスクの傾向を知ることができる
⚫ OWASPが公開するその他リソース
• Mobile Top 10 、 OWASP API Top 10
• ZAP(脆弱性診断ツール)、Testing Guide(テストフレームワーク)、ASVS(セキュリティコントロールフレームワーク)
アクセス制御の不備
不適切な暗号化
インジェクション
安全でない設計
不適切なセキュリティ設定
脆弱で古くなったコンポーネント
不適切な識別と認証
ソフトウェアとデータの整合性不備
セキュリティログとモニタリングの不備
サーバーサイドリクエストフォージェリ
(SSRF)
出典：OWASP Top Ten | OWASP®

View Slide

7
Copyright
想定される脅威：サイバー攻撃者の戦術とテクニックを知る
◼MITRE ATT&CK(マイター・アタック: Adversarial Tactics, Techniques, and Common Knowledge)
⚫ MITRE社の管理する、現実の観測に基づく、敵対戦術とテクニック(脅威)のナレッジベース
⚫ 偵察、初期アクセス、実行、永続化、権限昇格、探索など14プロセスで、どのような事が行われるかパターン化
➢ 敵対者の戦術とテクニックを知ることで、どのような脅威に対策をとるか想定し、具体的な対策に落とし込む
実行(Execution)
初期アクセス(Initial Access)
永続化(Persistence)
持出(Exfiltration)
権限昇格(Privilege Escalation) 認証情報(Credential Access)
探索(Discovery)
水平展開(Lateral Movement)
影響(Impact)
収集(Collection)
コマンドと制御(Command and Control)
攻撃資源開発(Resource Development)
偵察(Reconnaissance)
出典：MITRE ATT&CK®
防衛回避(Defense Evasion)

View Slide

8
Copyright
MITRE ATT&CK IaaS Matrix (公式IaaS特化版)
出典：IaaS Matrix | MITRE ATT&CK®
• 公開アプリケーションの悪用
• 信頼関係のある組織の悪用
• クラウドアカウントの窃取
実行(Execution)
• ユーザーの誤操作誘発
• アカウントの操作、作成
• マシンイメージへの埋め込み
権限昇格(Privilege Escalation)
• FWの無効化、ログの消去
• クラウドインフラの変更
• 未使用リージョンの利用
• 代替認証情報の利用
認証情報(Credential Access)
• ブルートフォース
• Web認証情報の偽造
• 多要素認証リクエストの発行
• ネットワークフィッシング
• 保護されていない認証情報
探索(Discovery)
• クラウドアカウントの探索
• クラウドインフラ、サービス、オブジェ
クトストレージ、ネットワークの検出
• ネットワークスニッフィング
• ソフトウェアの特定
• 管理コンソールへのアクセス
• 管理用アクセス経路の特定
• パスワードポリシー、権限の特定
• 代替認証情報の利用
収集(Collection)
• 自動収集
• リポジトリデータの窃取
• オブジェクトストレージの窃取
• ステージング環境へのコピー
持出(Exfiltration)
• 他アカウントへデータ移送
影響(Impact)
• データの破壊
• データの暗号化（ランサム）
• データの改ざん
• エンドポイントサービスの拒否
• ネットワークサービスの拒否
• リソースの不正利用
➢ 攻撃者はアカウントをなんとか窃取しようとする

View Slide

9
Copyright
MITRE ATT&CK Containers Matrix (公式コンテナ特化版)
• 公開アプリケーションの悪用
• 外部リモートサービス(SSH,VPN)
• アカウントの窃取
実行(Execution)
• コンテナ管理コマンド
• コンテナのデプロイ
• コンテナオーケストレーションジョブ
• ユーザー実行(悪意あるイメージ)
• 外部リモートサービス
• マシンイメージへの埋め込み
• ホストへの侵入
• 権限昇格の悪用
• ホスト上にイメージを構築
• コンテナのデプロイ
• ホストインジケータの削除
• マスカレード
• 代替認証情報の使用
• ブルートフォース
• Web認証情報の偽造
• 認証情報の窃取
探索(Discovery)
• コンテナとリソースの検出
• ネットワークサービスの検出
• 権限グループの検出
• 代替認証情報の使用
影響(Impact)
• エンドポイント遮断
• ネットワーク遮断
• リソースハイジャック
出典：Matrix - Enterprise | MITRE ATT&CK®
➢ 攻撃者は権限昇格を利用し防衛を回避する

View Slide

10
Copyright
MITRE ATT&CK for Kubernetes (MS独自K8s特化版)
• クラウドプロバイダ認証情報悪用
• レジストリに攻撃用イメージを配布
• Kubeconfig fileの悪用
• アプリケーションの脆弱性を突く
• 連携サービスの公開I/F悪用
実行(Execution)
• コンテナ内に侵入し攻撃
• bash/cmd、SSHの悪用
• Application exploit (RCE)
• 攻撃用Podを作成
• 攻撃用サイドカーを設置
• バックドア用コンテナを作成
• ノードのファイルシステムにアクセス
• Cronjobで定期実行
• アドミッションコントローラー悪用
• 特権コンテナ、hostPathマウント
• クラスタ管理者バインディング
• クラウドプロバイダ認証情報窃取
• コンテナのログを消去
• Kubernetesのeventを消去
• コンポーネントに似た名前に偽装
• Proxyでアクセス元を隠ぺい
• Secretsのリスト化、プリンシパル
• ServiceAccountを窃取
• マネージドIDのトークンを窃取
• アドミッションコントローラーの悪用
探索(Discovery)
• Kubernetes API Serverの探索
• Kubelet APIの探索
• Pod Networkのマッピング
• ダッシュボード、メタデータ
• クラウドのリソースへアクセス
• コンテナサービスアカウント
• クラスタ内NWへのアクセス
• 設定ファイル内の認証情報窃取
• ホストの書き込み可能volマウント
• Core DNS情報書き換え
• ARP poisoning と IP spoofing
収集(Collection)
• 非公開レジストリのイメージを窃取
影響(Impact)
• クラスタのデータを削除
• クラスタのリソースを不正利用
• サービスの停止
出典：Secure containerized environments with updated
threat matrix for Kubernetes | Microsoft
➢ 攻撃者は脆弱性を足がかりに、侵入先を広げる

View Slide

11
Copyright
脆弱性があることを知る
◼CVE(共通脆弱性識別子)
⚫ MITRE社が管理する一般公開されているセキュリティ脆弱性のリスト
⚫ 世界中のITベンダー、セキュリティ企業、リサーチ組織がCVE採番機関(CNA)として登録、報告
➢ このリストや通知情報から、自組織の利用するプロダクトに該当する脆弱性を特定、対策を検討
出典：CVE Details | MITRE

View Slide

12
Copyright
クラウドネイティブセキュリティとは？
◼CNCF Special Interest Group for Security (SIG-Security) のビジョン
⚫ リスク（脅威と脆弱性）を把握し、セキュリティポリシーが反映・持続された状態
”オペレーター、管理者、開発者が、自信を持って新しいクラウドネイティブアプリケーションを作成できるような未来があります。
彼らは、リスクを明確に理解し、セキュリティポリシーでの決定が、デプロイされたソフトウェアに反映されていることを検証でき
る状態で、クラウド技術を使用しています。”
⚫ ツールによるセキュリティ対策の省力化・自動化を想定
”私たちは、クラウドネイティブのオペレーター、管理者、および開発者のエクスペリエンスを簡素化することができる、次のよう
なツールのエコシステムが存在することを想定しています。“
1. 増え続けるシステムの異質性を理解し、それに対応し、ユーザーにサービスを提供しながらリソースとデータを保護するためのフレーム
ワークを提供する、システム・セキュリティ・アーキテクチャ
2. 開発者がシステムセキュリティ要件を満たすアプリケーションを簡単に作成・展開できるようにする、共通語彙とOSSライブラリ
3. 監査や説明可能な機能など、システムのセキュリティについて人々が推論することを可能にする、共通ライブラリとプロトコル
出典：https://github.com/odenyirechristopher/sig-security#vision

View Slide

13
Copyright
クラウドネイティブセキュリティホワイトペーパー
◼CNCF Security Technical Advisory Group(TAG) 発行のホワイトペーパー
⚫ クラウドネイティブは、迅速な開発とデプロイに焦点があり、セキュリティの懸念は複雑化
• ライフサイクルフェーズ（開発・配布・デプロイ・ランタイム）全体でセキュリティ対策
• ランタイムは、さらに実行環境、Access、Compute、Storageレイヤーで分けて考える
• CI/CDパイプラインに沿った自動化が必要、反応的なセキュリティから予防的なセキュリティへ
• 最小権限の原則、役割と権限、ゼロトラストアーキテクチャ
⚫ 脅威を想定
• OWASP脅威モデリング、MITRE ATT&CK Framework の活用
⚫ 準拠にはセキュリティベンチマークを活用
• NIST SP800-190 Application Container Security Guide
• NIST SP800-204 Security Strategies for Microservices-based Application Systems
• Center for Internet Security(CIS)、OpenSCAP など
• 業界ごとの規制基準（PCI-DSS、HIPAA、FedRAMP、GDPRなど）
出典：tag-security/security-whitepaper at main · cncf/tag-security · GitHub

View Slide

14
Copyright
クラウドネイティブセキュリティホワイトペーパー v2 Update
◼2020/11 v1 → 2022/5 v2 での追加事項
⚫ セキュアなデフォルト8原則 1.セキュリティは設計要件 2.セキュアな構成はユーザーエクスペリエンスが最高
3.安全でない状態は意識して決定（リスク許容） 4.安全な状態へ移行可能
5.セキュアなデフォルトは継承可能 6.例外リストを実装し必要な特権のみ付与
7.デフォルト準拠で脆弱性から保護 8.セキュリティ制限の説明責任
⚫ サプライチェーンセキュリティソフトウェア部品表(SBOM)：Software Supply Chain Security Best Practices
⚫ GitOps 開発とデプロイを分離、早い段階から脆弱性の排除が可能
⚫ セキュリティスタックライフサイクルごとの利用ツール：Cloud Native Security Map
⚫ マッピング：NIST SP800-218 Secure Software Development Framework(SSDF) v1.1
MITRE ATT&CK Threat matrix for Containers
⚫ ユースケース：ランサムウェア、EU規制による金融機関のセキュリティ保護
出典：Announcing the Refreshed Cloud Native Security Whitepaper | CNCF

View Slide

15
Copyright
新たな責任共有モデル
◼IaaS / PaaS / SaaS 以外の as-a-Service が増え、クラウドネイティブが担うレイヤーが細分化
⚫ セキュリティはレイヤーごと考えて対策する必要があるが、レイヤーが複数に渡るため対策が困難
出典：クラウドコンピューティングの進化と新たな責任共有モデル | CSA
OS
データ
仮想化
物理
オンプレ
アプリ
ミドル
従来モデル
（NIST SP800-145)
OS
データ
仮想化
物理
PaaS
アプリ
ミドル
OS
データ
仮想化
物理
アプリ
ミドル
IaaS
OS
データ
仮想化
物理
SaaS
アプリ
ミドル
(Cloud Security Alliance)
利用者責任のクラウド
「における」セキュリティ
クラウドプロバイダ責任の
クラウド「の」セキュリティ

View Slide

16
Copyright
はじめに
01
02
03
04
まとめ
05

View Slide

17
Copyright
The 4C's of Cloud Native security
◼クラウドネイティブセキュリティのコンテキストで考えるk8sセキュリティモデル
⚫ レイヤーごとの主な対策について整理されている
⚫ レイヤーに対応するガイドラインを用意
出典：Overview of Cloud Native Security | kubernetes.io
レイヤーレイヤーごとの主な対策 NRIのガイドライン
Code ・TLS接続、ポート制限、3rdパーティ依存関係の検証
・SAST、Dynamic probing attacks（OWASPツール）
・Webアプリケーション
・スマートフォンアプリケーション
Container ・OSセキュリティ
・脆弱性スキャン、イメージ署名、特権ユーザ禁止、セキュアな
ランタイム・OS
・Docker/Kubernetes
Cluster ・クラスタ保護
・コンポーネント（RBAC、認証、シークレット管理、etcd暗号
化、ポッドセキュリティ、ネットワークポリシー、TLS）
Cloud/Co-Lo
/Corporate DC
・クラウドプロバイダーのセキュリティ
・インフラ（コントロールプレーン、ノード、etcd）
・クラウド

View Slide

18
Copyright
NRIにおけるセキュリティガイドライン
◼各レイヤーごとに規程・ガイドラインが存在、プロジェクトごとに適したガイドラインを参照
⚫ ガイドラインが準拠する法規・基準・スタンダードが何か、根拠がなにか、説明を求められる
Webサイト運営
インターネット公開サーバ
Webアプリケーション
スマートフォンアプリケーション
データベース
OS
クラウド
バージョン管理
OS
データ
仮想化
物理
アプリ
ミドル
Docker/Kubernetes
機密情報・個人情報管理
CIS Benchmark、CIS Control、MITRE ATT＆CK
FISC、PCIDSS、NISTなど
各ベンダーのベストプラクティスなど
関連法規など

View Slide

19
Copyright
代表的なセキュリティフレームワーク
◼デファクトスタンダードとなっているセキュリティフレームワークは以下
それぞれサイバー攻撃対策・内部不正対策、組織面・技術面の四象限で特色あり
⚫ NIST CSF：米国立標準研究所(NIST) 発行のCyber Security Framework(CSF)
⚫ CIS Controls：米インターネットセキュリティセンター(CIS) 発行のセキュリティ管理策
⚫ ISMS： JISQ27001(ISO/IEC27001) に基づいた情報セキュリティ管理の仕組み
⚫ PCI DSS：クレジットカード業界セキュリティ団体(PCI SSC) 発行の対策基準
◼クラウドサービス利用時のセキュリティ判断基準
➢ NRIでは、サイバー攻撃対策に特化し、業界を問わず、
具体的な技術面での対策・設定に強みを持つ
CISの提供するリソースを活用
出典：【解説】NIST サイバーセキュリティフレームワークの実践的な使い方 | NRIセキュア

View Slide

20
Copyright
(参考)セキュリティフレームワークやナレッジの利用例
◼セキュリティフレームワークやナレッジを活用したセキュリティ対策の評価・分析手法
◼セキュリティベンチマーク／コントロールでの対策／方針と、セキュリティフレームワークとのマッピング
出典：NRIセキュア | MITRE ATT&CKを用いたサイバー攻撃対策の評価サービス
IM-1: 一元化された ID と認証システムを使用する
CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
3.12, 13.4, 4.4 AC-4, SC-2, SC-7 1.1, 1.2, 1.3
セキュリティの原則: 一元化された ID と認証システムを使用して、クラウドリソースと非クラウドリソースに対する組織の ID と認証を管理します。
出典：Azure セキュリティベンチマーク | Microsoft
出典：Microsoft | MITRE ATT&CK® と組み込
み Azure security control とのマッピングを発表

View Slide

21
Copyright
Center for Internet Security(CIS)の提供リソース
◼米国の政府・学術機関・企業がインターネット・セキュリティ標準化に取り組む団体
⚫ CIS Controls：サイバー攻撃に焦点を当てた具体的技術対策を示す18種類のフレームワーク
⚫ CIS Benchmarks：セキュリティ推奨事項・設定値を記載したドキュメント
出典：CIS Center for Internet Security
責任共有モデルのどのレイヤーをカバーするか

View Slide

22
Copyright
NRIにおけるクラウドネイティブセキュリティガイドラインの構成
◼独自ルール／ベストプラクティス／CIS Benchmarkの三階建て、メガクラウドは個別詳細版あり
⚫ 権威あるスタンダードとして、MITRE ATT&CK および CIS Control とマッピング、脅威・根拠・対策を横串
Oracle Cloud
ガイドライン
Google Cloud
ガイドライン
AWS
ガイドライン
Azure
ガイドライン
クラウドガイドライン(共通)
CIS
Control
MITRE
ATT&CK
ベースライン：
サイバー攻撃
対策フレームワーク
リスクベース：
想定される脅威
個別サービスごとの設計方針・設定方法
Alibaba Cloud
ガイドライン※
各クラウドのベストプラクティス（設定・方針が個別）
CIS Benchmark（設定は個別だが、方針は共通）
自社ノウハウをもとにした独自ルール（共通）
NRI独自サービス、CSPM、クラウドプロバイダのセキュリティチェック・可視化サービスで自動化
過去の運用から得られた独自の知見
各クラウドサービスのアカウントを監視、違反があれば利用者へ通知
※整備中

View Slide

23
Copyright
「クラウドのセキュリティ」は信頼できるのか？
◼クラウド事業者の責任は果たされているか？
⚫ 責任を共有するには、利用するクラウドサービスが信頼できるか、コンプライアンスの観点で判断する
⚫ 企業のセキュリティポリシーに合致するか、独自の質問票（セキュリティチェックシート）を用意するケースもある
が、クラウドサービス事業者と一問一答をやり取りするのは双方ともに非常に労力・時間がかかる
◼コンプライアンスに関しては、以下のような第三者基準の認証取得状況を確認
⚫ ISO27001：情報セキュリティマネジメントシステム(ISMS)
⚫ ISO27017：クラウドベースの情報セキュリティの統制
⚫ ISO27018：クラウド上での個人データ保護
⚫ SOC1：財務報告に係る内部統制報告書
⚫ SOC2：セキュリティや可用性等の内部統制報告書
⚫ HIPPA、PCI-DSS、FISCなど：特定業界ごとの統制基準
⚫ ISMAP、FedRAMP / SP800-53、NIST SP800-171、GDPR、マイナンバー法など：国ごとの統制基準
NRIでは第三者認証の取得状況に応じ、
クラウド事業者のセキュリティ対策が実
施済みと判断し、セキュリティアセスメント
を省略可としている

View Slide

24
Copyright
「クラウドにおけるセキュリティ」をどう対策するか？
◼CIS Benchmarks は、非常に広範囲な製品・サービスを対象とするドキュメント群
⚫ 各クラウドプロバイダ、Docker/Kubernetes、OS/ミドルなどをカバー
⚫ 以下の観点では対策が手薄なので、追加対策を実施
• コンテナイメージの署名、レジストリの定期・依存関係先スキャン、CI/CDパイプライン保護、バージョン管理
カテゴリ対象の製品・サービス(例)
Cloud Provider Alibaba Cloud, Amazon Web Services, Microsoft Azure, Google Cloud Platform, IBM Cloud, OCI
Desktops & Web Browsers
Apple Desktop OSX, Apple Safari Browser, Google Chrome, Microsoft Internet Explorer, Microsoft Windows Desktop 10/XP/NT,
Mozilla Firefox Browser, Opera Browser, Mobile Devices, Zoom
Mobile Devices Apple Mobile Platform iOS, Google Mobile Platform
Network Devices
Agnostic Print Devices, Check Point Firewall, Cisco Firewall Devices, Cisco Routers/Switches IOS, Cisco Wireless LAN Controller,
Juniper Routers/Switches JunOS, Palo Alto Networks
Server Software
- Operating Systems
Amazon Linux, CentOS, Debian Linux Server, IBM AIX Server, IBM Z series, Microsoft Windows Server, Novell Netware, Oracle
Linux, Oracle Solaris Server, Red Hat Linux Server, Slackware Linux Server, SUSE Linux Enterprise Server, Ubuntu LTS Server
Server Software
- Other
Apache HTTP Server, Apache Tomcat Server, BIND DNS Server, FreeRADIUS, Microsoft IIS Server, IBM DB2 Server, Microsoft
Exchange, Microsoft SharePoint Server, Microsoft SQL Server, MIT Kerberos, MySQL Database Server, Novell eDirectory,
OpenLDAP Server, Oracle Database Server, PostgreSQL Database Server, Sybase Database Server
Security Metrics Quick Start Guide, Security Metrics
Virtualization Platforms Agnostic VM Server, Docker, Kubernetes, VMware Server, Xen Server
Other Microsoft Access, Microsoft Excel, Microsoft Office, Microsoft Outlook , Microsoft PowerPoint, Microsoft Word
出典：CIS Benchmarks | CIS

View Slide

25
Copyright
CIS Cloud Provider Benchmarks
◼ 主要なパブリッククラウドのIaaS中心の対策
• ①IAM、②ネットワーク、③コンピュート、④ロギング／モニタリング、⑤セキュリティ／コンプライアンスの５分類
• 各クラウドベンダごとに利用できる機能、設定の細かさ・複雑さが異なるが、考え方は共通
• 上記をベースに、各クラウドのベストプラクティスや、自組織のセキュリティ要件を加えてガイドライン化
AWS Azure Google Cloud OCI Alibaba Cloud
Version 1.4.0 1.4.0 1.3.0 1.2.0 1.0.0
最終更新 2021/5/28 2021/11/26 2022/3/31 2022/4/13 2020/12/11
① IAM 21 23 15 13 16
② Networking 4 6 10 8 5
③ Compute VM - 7 11 - 6
Storage 7 11 2 6 9
Database - 18 30 - 9
Serverless - 11 3 - -
④ Logging / Monitoring 11+15 15 12 16 23
⑤ Security / Compliance - 15+5 - 2 8
合計 58 111 83 45 76

View Slide

26
Copyright
CIS Cloud Provider Benchmarks での対策
◼ 主要なパブリッククラウドのIaaS中心の対策
① IAM(Identity and Access Management)
• 最小権限、パスワードポリシー、MFA、プリンシパル
• クレデンシャル、APIキー、rootユーザの利用制限
② ネットワーク
• プロトコル・ポート制限、 from IP制限
• 許可されたソースのみに制限
③ コンピュート
• プロトコル・ポート制限、パブリック公開制限
• 暗号化、CMK・BYOK、ローテーション
④ ロギング／モニタリング
• ログ記録、保管、監視、作成・変更・削除の通知
• タグ、分析、監査
⑤ セキュリティ／コンプライアンス
• セキュリティ状況の検査、分析、可視化、アドバイザリ
• 自社セキュリティ／コンプライアンスサービスの有効化
②ネットワーク／③コンピュート
①IAM
④ロギング／モニタリング ⑤セキュリティ／モニタリング
Subnet C
10.0.30.0/24
Subnet D
10.0.30.0/24
Subnet B
10.0.30.0/24
REGION
Availability Zone 1 Availability Zone 2 AZ3
Subnet A
10.0.30.0/24
Bastian Server
Primary
Database
Loaded Balanced
Web Servers
Standby Database
Database
System
Object
Storage
Identity &
Access
Management
VPN
Bare
Metal
Compute
Database
System
Gateway
VCN
Load
Balancer
Virtual Machine
Virtual Machine
Notifications
Alarming Monitoring
Healthcheck Tagging
Auditing
Logging
Secur
ity
Lists
Policies
Groups

View Slide

27
Copyright
CIS Kubernetes Benchmarks
◼ Kubernetes、主要なパブリッククラウドのマネージドKubernetesサービス、OpenShiftの対策
• ①コントロールプレーンのコンポーネント、②設定、③ワーカーノード、④ポリシー、⑤関連サービスの５分類
• 各クラウドベンダごとに利用できる機能、設定の細かさ・複雑さが異なるが、考え方は共通
• マネージドKubernetesサービスを利用すると、コントロールプレーンの対策①が不要に（②の一部設定だけ）
• ワーカーノードにFargateなどのサーバレスを利用すると、ワーカーノードの対策③も不要となる
Kubernetes Amazon EKS Azure AKS Google GKE Oracle OKE Alibaba ACK
RedHat
OpenShift
Version ー 1.1.0 1.1.0 1.2.0 1.1.0 1.0.0 1.2.0
最終更新 2022/5/13 2022/4/13 2022/02/04 2021/11/16 2022/6/23 2021/3/4 2022/6/22
① Master (Control Plane)
Components
41 ーーーー 41 65
② Master (Control Plane)
Configuration
21 1 1 3 7 21 3
③ Worker Node 23 16 15 16 16 20 23
④ Policies 30 22 23 24 22 24 24
⑤ Managed Service / etcd 7 13 15 37 12 17 + 7 7
122 52 54 80 67 130 122

View Slide

28
Copyright
CIS Kubernetes Benchmarks での対策
◼ 構成要素ごとにセキュリティ対策を実施
① コントロールプレーンのコンポーネント
• APIサーバー、コントローラーマネージャー、スケジューラーの設定
② コントロールプレーンの設定
• 設定ファイルのパーミッションとオーナー、認証認可、ロギング
③ ワーカーノード
• 設定ファイルのパーミッションとオーナー、kubelet、コンテナ用OS
④ ポリシー
• RBACとサービスアカウント、Pod Security Standards、ネットワー
クポリシーとCNI、シークレット管理、アドミッションコントロール
⑤ 関連サービス
• etcd
• クラウドプロバイダ提供：レジストリとイメージスキャン、IAM連携、
KMS、メタデータ保護、ノードの保護、クラスタネットワーク構成、
ロギング、認証認可の連携、ストレージ暗号化キー、権限継承に
よる全体保護、セキュリティサービスとの連携
①②
kubectl
Container registry
Image Image Image
docker
Infrastructure [Node, Metadata, Network, …]
Infra cmd
manifest API Server
[Pods, services, …]
Scheduler Controller
Manager
etcd
Docker
Kubelet Proxy
Worker
Docker
Kubelet Proxy
Docker
Kubelet Proxy
Pod Pod Pod Pod
Pod Pod Pod
Master
Cloud Managed Service [IAM, KMS, Logging, …]
③
⑤
④
①②

View Slide

29
Copyright
ケーススタディ：脆弱性スキャンは定期的・依存関係先まで必要
◼事象：Log4j の脆弱性がパッケージに含まれるコンテナイメージが長期間認知されず
⚫ 2021年12月頭に Amazon ECR にイメージプッシュ、認知が2022年5月
◼原因：イメージの脆弱性スキャンが不十分
⚫ 該当箇所のCI/CDが実行されない：もともと更新頻度が少ない箇所に使われていた
⚫ 定期的な脆弱性スキャンの未実施：プッシュ時スキャンしかしていなかった（Log4j公知はプッシュ後）
⚫ 依存関係先のパッケージまで未検査：ベーシックスキャンの仕様認識が不十分だった（ClairのCVEベース）
◼対策：脆弱性スキャンを定期的に実行し、依存関係先までスキャン
⚫ 該当箇所のCI/CDが実行されない： CloudWatch Events から Lambda で手動スキャンを定期実行
⚫ 定期的な脆弱性スキャンの未実施：（同上）
⚫ 依存関係先のパッケージまで未検査： Inspector統合の拡張スキャン、Trivy による依存関係先スキャン

View Slide

30
Copyright
◼各サービスごとに設定できる対策と想定される脅威は様々だが、大別して７つを設定
対策の大項目想定される脅威
1. アイデンティティによる認証・認可、MFA 不正アクセス、アカウント乗っ取り、過大権限による誤操作
2. ネットワークによるアクセス制御・境界線防御インターネットからのログイン施行、侵入・攻撃
3. 暗号化による保存データ・通信経路の保護情報漏洩、盗聴、改ざん
4. 多重化・冗長化構成による可用性の向上 HW故障、SW障害、広域障害
5. バックアップ取得によるデータロストへの備え運用ミス、データセンター被災、ランサムウェア
6. ロギング・モニタリングによる記録・監視攻撃、不正行動
7. 分析・レポーティングによる可視化・監査攻撃、障害、設定不備の見落とし
◼ セキュリティ以外の関連する観点も追加し、より包括的なガイドラインを作成
8. 統制レベルに応じたアカウント分割コンプライアンス違反、本番環境とその他環境の混同
9. 予算設定、利用金額超過アラート使い過ぎ、無駄なリソース利用、不正利用
NRIのガイドラインの考え方

View Slide

31
Copyright
◼ルール、適用・検知、利用者の対処、教育・啓蒙を通じ、継続的な対策の普及を推進
• ガイドライン適用の維持
• 違反通知へのアクション
• 調査、アナウンス対応
• e-Learning
• 研修、勉強会
• 連絡会、社内アナウンス
• クラウド利用申請・審査
• アカウントの棚卸・調査
• ガイドライン準拠状況の
チェック・通知サービス
• 各種社内規程
• クラウドガイドライン
• 脆弱性／セキュリティ
アップデート対応
ルール
適用・
検知
利用者
の対処
教育・
啓蒙
NRIにおけるクラウドセキュリティの取り組み

View Slide

32
Copyright
ガイドラインが活用される工程は限定的
◼課題：従来のガイドラインを用いた品質担保を実施する運用では、カバーされる工程が少ない
⚫ 企画の最上流、実装～テスト中盤、リリース運用では、ドキュメントであるガイドラインが活用されにくい
➢シフトレフト、CI/CD・DevSecOps、継続監視・通知、セキュリティの可視化・自動化が必要
企画要件定義設計実装テスト
リリース
運用
テストフェーズ終盤～リリース前に、
Web/プラットフォーム診断を実施
セキュリティホールの発見・対策
開発工程
アプリケーション、OS/ミドル、Docker/Kubernetes、
クラウドの各セキュリティガイドラインを参照
推奨される要件定義・設計・実装のチェック
CI/CDパイプライン、DevOpsループ
SAST/DAST/SCA/IAST の組み込み
持続可能なセキュリティ
CSPM/CWPP/etc
セキュリティのシフトレフト
Security by Design
従
来
今
後

View Slide

33
Copyright
はじめに
01
02
03
04
まとめ
05

View Slide

34
Copyright
ガイドラインによる目検に追加で、システム化によるチェックが必要
◼NRIとしてクラウドにおける各種サイバーセキュリティフレームワークを含めるようになった
⚫ CIS Benchmarks、CIS Controls
⚫ MITRE ATT&CK Framework
◼課題の再定義
⚫ セキュリティ監査が行われる前後でしかガイドラインが参照されない問題
⚫ 継続してセキュリティチェックを自動化し、開発や運用の現場が継続して確認可能か
◼以降、いくつかのアプローチを紹介
⚫ 初学者向けにもいくつかのキーワードについて説明しているスライドがあるので参考にしてください
• 想定される運用設計課題についても記述
⚫ 最後にイケてるツールをいくつか紹介
• すべてのサービスをすべて検証したわけではないのでご注意ください

View Slide

35
Copyright
責任共有モデルと技術的アプローチによるカバー
◼技術的アプローチを後ほど、責任共有モデルにマッピング

View Slide

36
Copyright
CSPM(Cloud Security Posture Management)
◼CSPM(クラウドセキュリティ態勢管理)
⚫ クラウドセキュリティの構成不備・管理不備・リスクを可視化し、レスポンスを行うための仕組み
◼CSPMの運用課題と対応
⚫ チェック結果を受けた利用者がどう能動的に動いてくれるか
• 週次・月次定例の開催など、強制的に実施する文化を採用
⚫ 初期導入後のアラート数の多さ
• リスクベース・脅威ベースアプローチから、アラートの対応優先度をマッピング・取捨選択
AWS Security Hub
Google Cloud
Security Command Center
Microsoft Defender for Cloud
Oracle Cloud Guard
管理対象とするIaaSサービスと紐づけ、リソースを発見する
脆弱な設定や設定不備をカスタムポリシーで自動修復
マルチクラウドの一元統制管理
コンプライアンス確認
Palo Alto Networks
Prisma Cloud
Checkpoint CloudGuard

View Slide

37
Copyright
CWPP(Cloud Workload Protection Platform)
◼CWPP(クラウドワークロード保護プラットフォーム)
⚫ VMやコンテナ、サーバーレスなど様々なワークロードを保護する仕組み
⚫ CI/CD上ではコンプライアンス違反してるもの等を検査、デプロイされた環境ではさらにランタイム保護、外部から
のAPI保護等が可能となり、ワークロードのリスクを可視化し、コントロールするための仕組み
◼CWPPの運用課題と対応
⚫ 開発者のデリバリに応じてCWPPの設定追従できるだけのアジリティを確保
• 3rdベンダーのサービスにおいても、IaCで設定できるものはDevSecOpsの各種工程内で極力実施
⚫ サーバーレスサービス向けのカバー範囲の狭さ
• OWASP Serverless Top10あるいはSAS12(※)、OWASP ASVSやチートシートシリーズで対策
Google Cloud
Security Command Center
Microsoft Defender for Cloud
開発段階でのスキャン
ランタイム保護
Aqua CSP
Sysdig Secure
Palo Alto Networks
Prisma Cloud
WAAP保護
脅威(マルウェアや不正プロセス、不正アクセス)の検出
出典：The 12 Most Critical Risks for Serverless Applications | CSA

View Slide

38
Copyright
マルチクラウドの一元統制管理
CIEM(Cloud Infrastructure Entitlements Management)
◼CIEM(クラウドインフラストラクチャ権限管理)
⚫ クラウドリソース(APIのアクセス元とアクセス先)、IAM、内部脅威に対し、権限昇格の対策やラテラルムーブメン
トの抑制、ガバナンスと可視化を提供する仕組み
◼CIEMの運用課題と対応
⚫ チェック結果を受けた利用者がどう能動的に動いてくれるか
• 週次・月次定例の開催など、強制的に実施する文化を採用
• クラウドにて追加提供されるサービスの権限付与に対して、ワイルドカードの禁止等適切な権限管理追従
• 使われていない認証の棚卸
Microsoft Entra
Permissions Management
クラウド上の権限のガバナンス
最小権限の構成
マルチクラウドにおけるガードレール、ランディングゾーンの構成
Palo Alto Networks
Prisma Cloud
Zscaler Cloud Protection
(Trustdome)
Sysdig Secure CIEM

View Slide

39
Copyright
責任共有モデルと技術的アプローチによるカバー
◼CSPM、CWPP、CIEMを当てはめると以下のような範囲をカバー
⚫ ベンダーがデフォルトで設定してくるアンセキュアな設定をCIEMで一部対応
CSPM
CWPP
CIEM
CWPP
CIEM

View Slide

40
Copyright
IaC Security (Infrastructure as Code Security)
◼IaC Security
⚫ 設定不備や脆弱性が含まれるIaCテンプレートを事前にスキャンし、セキュリティリスクを可視化、低減するための
アプローチを把握する仕組み
◼IaC Securityの運用課題と対応
⚫ Terraform、CloudFormation、Azure Resource Manager、Kubernetes以外のIaCへの対応は遅延
• OSSのLintツールなどで凌ぐことと、CSPMで指摘されるセキュリティ対策の掛け算でセキュリティレベルを向上
AWS CloudFormation
Guard(cfn-guard)
Microsoft Azure Policy
Snyk Infrastructure as Code
セキュアなIaCテンプレートの維持
最小権限の構成
マルチクラウドにおけるガードレール、ランディングゾーンの構成
コンプライアンス確保
Palo Alt Networks
Prisma Cloud
(Bridgecrew Checkov)
Google Risk Compliance
as Code(RCaC)

View Slide

41
Copyright
セキュア化させるCI/CD
セキュリティテスト
Apps & Data Security
◼Apps & Data Security(アプリケーションとデータのセキュリティ)
⚫ アプリケーションやAPI、アプリケーション内に含まれるデータやコードを盗聴、搾取、改ざんされないための仕組み
◼Apps & Data Securityの運用課題と対応
⚫ 既知の脆弱性への対策、アプリケーションのセキュリティ対策がおろそか
• クラウドネイティブのセキュリティサービスの活用、脅威への対策、DLPの活用
• OSSの既知の脆弱性とライブラリの依存関係の早期確認
• 脆弱性診断(SAST、DAST)をBuild/Ship/RunあるいはCI/CDに取り込んだセキュリティ対策とアジリティ確保
• ペンテストを活用し、上記ツールでは見つけられない、脆弱性と侵入方法の調査と対策
WAF
DDoS
ボット対策
暗号化対策
アプリケーションやAPIのセキュリティ
不要なデータを保持しない (Need To Know)
コードレベルでのセキュリティ強化
Security by Design
守るべきアプリ、データ、その所在、優先順
位は明確になっていることが大前提
アクセス制御
脆弱性管理
セキュリティ監視

View Slide

42
Copyright
CNAPP(Cloud Native Application Protection Platforms)
◼CNAPP(クラウドネイティブアプリケーション保護プラットフォーム)
⚫ “CSPM” + “CWPP” + “CIEM” + “IaC Security” + “Apps & Data Security”
⚫ 可視化とコントロールの圧倒的向上
⚫ 開発から運用まで、クラウドネイティブアプリケーションのライフサイクル全体を
カバーする統合セキュリティアプローチを実装することが可能
⚫ アプリケーションやデータのセキュリティも対策として考えられる、
CNAPPこそ最強
CSPM
CWPP
CIEM IaC
Security
Apps&Data
Security
CNAPP
※ベンダーによって、CNAPPの定義などは異なる

View Slide

43
Copyright
CNAPPがカバーする責任共有モデル
◼CNAPPがカバーする責任共有モデル
⚫ 現状、NoCodeをカバーするサービスは国内ではあまり見かけることができず、今後に期待
CNAPP
CSPM
CWPP
CIEM
IaC Security
Apps&Data Security
Apps&Data Security
CWPP Apps&Data Security
Apps&Data Security CIEM

View Slide

44
Copyright
シフトレフトセキュリティの採用
◼CNAPPにおけるセキュリティはシフトレフトすることでより力を発揮
⚫ 先の発表にもあったクラウドネイティブセキュリティガイドラインを利用したSecurity by Designを採択
⚫ 早期時点で脆弱性や設定不備を把握し、セキュリティテストと修正におけるコストの削減
システム企画
要件定義
基本設計
詳細設計
構築・設定
単体・結合テスト
システム・運用テスト
サービス要求にかかるリスクの検討不足により、システム化計画の目的が達成されない
サービス要求のシステム要件への落とし込みの不足により、想定すべき脅威を見逃す
セキュリティ要件の検討不足により、システムの方式や運用にかかるリスクの考慮が漏れる
セキュリティ仕様の実装方針の検討不足により、アプリ・基盤の既知の脆弱性の考慮が漏れる
コーディング規約や検査不備により実装段階での考慮が不足し、既知の脆弱性の考慮が漏れる
設定レベル・機能レベルでの安全性検証不足により、セキュリティの実装不備や脆弱性を検出できない
システム全体の安全性の検証不足により、セキュリティ要件の実現不備や脆弱性を検出できない
ShiftLeft
早期時点から、
◼ CSPM
⚫ リスク検出数の抑止
◼ CWPP
⚫ 脆弱性検出数の抑止
◼ CIEM
◼ IaC Security
◼ Apps&Data Security
⚫ 脆弱性検出数の抑止
考えられるリスク

View Slide

45
Copyright
Apps & Data Securityの課題
◼アプリケーションおよびデータのセキュリティの課題
⚫ アプリケーションの脆弱性管理とデータに対する脅威の管理
⚫ その他
• アセット管理(ITAM)
• クラウドセキュリティアクセスブローカー(CASB)
• サービス管理(ITSM)
• SaaS管理プラットフォーム(SMP)
• SaaS Security Posture Management(SSPM)
◼アプリケーションおよびデータのセキュリティを可視化する方法
⚫ 組織として開発・運用するアプリケーションやデータのセキュリティ状況の可視化
⚫ リアルタイムにいまそのアプリケーションに対して何が起きているのかを可視化
◼上記を満たすことが出来そうな技術といえば？
ここでは公開システム/サービスについて言
及していく

View Slide

46
Copyright
Observability
◼Observability (可観測性)
⚫ 外部出力からシステムの内部の状態をどれだけよく理解できるかを測定・可視化する仕組み
⚫ 監視の事前定義が困難であっても、その影響から原因への移動・遷移が可能
◼Observabilityの運用課題と対応
⚫ 複雑で大規模なマイクロサービスを可視化できても、エラー多すぎてエラーバジェットを使い切りがち
• エラーの原因究明と修正による信頼性回復、ポストモーテムの実施
Datadog
Oracle Cloud Infrastructure
Monitoring
Metrics：効率的かつ頻繁にヘルス情報・パフォーマンス情報を測定
Events：特定タイミングで発生する事象
Logging：処理内容に関する情報を記録したテキストデータ
Tracing：イベントの因果連鎖を追跡するもの
NewRelic
Splunk
Azure Monitoring
Amazon Cloudwatch、X-Ray
Google Cloud Monitoring
出典：Observability Conference 2022、オブザーバビリティから組織、ルールを見直した事例を紹介 | Think IT ここではNewRelicが定義する4つの
テレメトリーをもってObservabilityとする

View Slide

47
Copyright
◼SIEM(セキュリティ情報イベント管理)
⚫ ネットワークやセキュリティ機器のログ内のアクティビティを一元管理し、リアルタイムで脅威を検出し可視化する
仕組み
◼SIEMの運用課題と対応
⚫ アラート発生時におけるインシデントレスポンス・サイバーレジリエンスの体制
• トリアージやインシデントレスポンスはセキュリティ担当者が二次被害への抑制として担うとしても、その後の本格対策に
おいて、Dev、Sec、Ops担当者によるクロージング、経営層と一緒にレジリエンスを確保
⚫ アウトソースから自社運用に切り替えた際の、クラウドネイティブサービスにおけるオーナーシップの範囲の増加
• コストパフォーマンスを見ながら自動化に切り替えていく必要性
予防的捜索
SIEM(Security Information and Event Management)
MetricsやEvents、Loggingの一元集中管理
高度な相関分析
インシデントの早期発見
Splunk SIEM
SumoLogic Cloud SIEM
Microsoft Sentinel
Google Chronicle

View Slide

48
Copyright
◼SOAR(セキュリティのオーケストレーションと自動化によるレスポンス)
⚫ セキュリティ運用の自動化及び効率化を実現する仕組み
⚫ インシデントへの対応手順をプレイブックに作成が可能であれば、自動対処可
◼SOARの運用課題と対応
⚫ インシデント対処時の組織におけるパフォーマンスのばらつきの発生
• 各担当者の作業記録、作業時間などのパフォーマンスインジケータをもとに、組織内の改善計画立案
人材不足対応
SOAR(Security Orchestration, Automation and Response)
インシデント対処自動化
インシデント管理機能
セキュリティ運用部隊のパフォーマンス可視化
同一プラットフォーム内で業務プロセスの完結
Splunk SOAR
SumoLogic Cloud SOAR
Microsoft Sentinel
Google Chronicle
出典：SOARとは？セキュリティ運用の自動化により得られる３つのメリット | NRIセキュア

View Slide

49
Copyright
Cloud Nativeなシステムにおける、従来のSecurity Monitoringの限界
◼Cloud Nativeなシステムにおける、従来のSecurity Monitoringの限界
⚫ Metrics、Events、LoggingでSecurity Monitoringが行われてきた過去
• SIEMにおけるトラディショナルな相関分析もこの三つのテレメトリーを対象
⚫ 既知の脅威は定義の上で検出できても、未知の脅威の検出は不可
⚫ 複雑なマイクロサービス連携のおかげで、5W1Hの中でも、特にHowとWhereがわかりにくい状況
⚫ Cloud Nativeなシステムにおいて、ログ量が爆発的に増大して、分析が難解となり、その後の対応が人力では
困難

View Slide

50
Copyright
ObservabilityがCloud Native Securityと親和性よい理由
◼ObservabilityがCloud Native Securityと親和性よい理由
⚫ Tracingというテレメトリーを取り込むことで、
• APM(Application Performance Monitoring)の実施が可能
• 攻撃が行われていることを検出
• 脆弱性やリスクの表面化
⚫ HowとWhereが可視化され、マイクロサービス上のどこでどのように侵害されてるのか鮮明に理解
⚫ 未知の脅威や内部不正の検知にも有効
⚫ 自動化とプレイブックの作成による、セキュリティインシデント対応の効率化
⚫ CWPPを補完し、Apps & Data Securityの領域を可視化
Security Tracing

View Slide

51
Copyright
Security Tracing
◼Security Tracing
⚫ Tracingを使用して、マイクロサービスへの攻撃を特定して阻止
• リクエストが認証・認可含め、必要なサービスをすべて通過したか？
• リクエストが予期せぬサービスを呼び出したか？
• リクエストが不正なデータへのアクセスを許可したか？
• リクエストがシステムに入ってきた個所
• リクエストを発信したIPアドレス
• (場合によって)攻撃者が特定できるか？
⚫ 膨大なマイクロサービスでは可視化だけでは困難
⚫ 正常動作と異常動作を識別することを、機械学習とアノマリ検知の組み合わせで実現できると、マイクロサービ
スで連携されたアプリケーションの脆弱性を検出することが可能
⚫ より解像度高く何が起きたかを把握することが可能

View Slide

52
Copyright
Security Observability
◼Security Observability
⚫ 組織として開発・運用するアプリケーションやデータのセキュリティ状況とリアルタイムにいまそのアプリケーションに
対して何が起きているのかを可視化できる仕組み
⚫ 脆弱性管理はもちろん、公開されているアプリケーションやAPIなどにおける脅威の動向を可視化できる仕組み

View Slide

53
Copyright
既存Observabilityサービスにおけるセキュリティの課題
◼既存Observabilityサービスでは詳細に識別できないより細かなレベルでのトラフィックを見る必
要性
⚫ アプリケーションとネットワークのパフォーマンスモニタリング
⚫ サービスメッシュ、負荷分散、動的トポロジの継続的な検出
⚫ システムコール、パケットペイロードの監視
◼本課題を解決できる技術は二つあると考察

View Slide

54
Copyright
DPI(Deep Packet Inspection)
◼DPI(ディープパケットインスペクション)
⚫ ネットワークで何が起きているかをよく理解し、パケットの内容を細かく評価する仕組み
⚫ ヘッダー、フッターを見るだけではなく、ユーザー定義のルール、ポリシーに合致したものかを良いようにフィルタしてく
れるため、悪意あるパケットや侵入の特定、トラフィック管理に有用
⚫ ペイロードチェックの工程で、特定文字列(署名照合など)の確認を行うことも可能
◼過去の遺物ではなく、大規模に収集したデータを簡易に分析できる今、改めて見直されようとし
ている技術
Traffic

View Slide

55
Copyright
eBPF(Extended Berkeley Packet Filter)
◼eBPF
⚫ Kernelのソースコード変更もモジュール追加もなく、プログラムを実行することができるKernel技術
⚫ Linux Kernel内の軽量なサンドボックスされたVMと見なして、特定のKernelリソースを利用したBPFプログラムを
実行
⚫ ObservabilityのためにeBPFを用いることで、セキュリティやネットワークなど観測以外の目的にも応用が可能
出典：What is eBPF? | ebpf.io

View Slide

56
Copyright
Security Observabilityを用いて成し遂げたい/成し遂げられること
◼Security Observabilityを用いて成し遂げたい/成し遂げられること
⚫ アプリケーションの脆弱性管理やデータにおける脅威の管理が可能
⚫ 脅威がシステムに侵入することを阻止、あるいは侵入されても、混乱が引き起こされる前に阻止
⚫ DevSecOpsにおける前工程において、脅威を防いで、効果的にDevとOpsを支援

View Slide

57
Copyright
Security Observabilityのツール紹介
◼Traceable / Traceable
◼Araali Networks / Araali Lens, Sense, Shield
◼Deepfence / ThreatMapper, ThreatStryker
◼Gigamon / Gigamon Hawk, ThreatINSIGHT

View Slide

58
Copyright
Traceable / Traceable
◼Traceable / Traceable
◼https://www.traceable.ai/
◼アプリケーションのランタイムにおけるAPIリ
スクの特定、内部・外部で悪用された
APIの検出、APIセキュリティのリスク評価

View Slide

59
Copyright
Araali Networks / Araali Lens, Sense, Shield
◼Araali Networks /
Araali Lens, Sense, Shield
◼https://www.araalinetworks.com/
◼Araali Lensで脅威検出し、Araali Sense
でリスクに優先順位を付け、 Araali
Shieldで適切に構成されたeBPFベースの
コントロールをクラウドに導入して、エクスプ
ロイトの可能性とデータ侵害の影響の両
方を管理

View Slide

60
Copyright
Deepfence / ThreatMapper, ThreatStryker
◼Deepfence /
ThreatMapper, ThreatStryker
◼https://deepfence.io/
◼ThreatMapper：
⚫ クラウドネイティブなアプリの脆弱性と攻撃パス
を見つけ、そのエクスプロイトのリスクに基づいて
ランク付け
◼ThreatStryker：
⚫ DPI技術を用いて、IoAとIoCを見つけ、各攻撃
イベントについての相関分析をし、脅威を緩和
※IoC(Indicators of Compromise；侵害の指標)：IPアドレスやドメイン、URL、ハッ
シュなどシステムやネットワークのアーティファクトで構成される静的なオブジェクト
※IoA(Indicators of Attack；攻撃の指標)：悪意ある攻撃(不正コードの実行、永続
化の実施、C2の確立、防御回避)などのTTP(Tactics/Techniques/Procedures)で構成
されるもの

View Slide

61
Copyright
Gigamon / Gigamon Hawk, ThreatINSIGHT
◼Gigamon / Gigamon Hawk, ThreatINSIGHT
◼https://www.gigamon.com/
◼Hawk：
⚫ マルチクラウド・ハイブリッドクラウドのネットワーク全体を可
視化する”Deep Observability”
⚫ 既存利用しているObservabilityツールとの統合も可で、
米国国防総省でも利用
◼GTI：
⚫ 侵害されたデバイスと脅威を確認し、脅威におけるリスク
の動的計算とトリアージを自動化
⚫ DNSやSSLトラフィックをモニタリングし、行動特性を分析
出典：Gigamon Adds Crucial Network Visibility to Zero Trust at the Department of Defense |
Gigamon

View Slide

62
Copyright
Cloud Native SecurityとしてSecurity Observabilityの未来
◼“CNAPP” + “Security Observability” + “SIEM” + “SOAR”
⚫ 見るべき個所すべてが可視化
⚫ レイヤーごとに導入されていたツール間での分断がなくなり、
一貫したセキュリティ体制の実現が可能
⚫ Security Tracingを取り込んだSIEMによる相関分析と
プレイブック記載が可能なインシデントのSOARによる自動対応
CSPM
CWPP
CIEM
IaC
Security
Apps&Data
Security
Security
Observability
CNAPP
SIEM
SOAR

View Slide

63
Copyright
Cloud Native SecurityとしてSecurity Observabilityの未来
◼未来年表(色が濃いと運用が出来ている)
⚫ IaC Security以下、国内にて利用が開始し出すのは近い将来訪れるが、標準的に運用されるまではまだまだ
時間はかかる見込み
2018 2019 2020 2021 2022 2023 2024 2025 2026 2027
CSPM
CWPP
IaC Security
CIEM
CNAPP
Security
Observability

View Slide

64
Copyright
はじめに
01
02
03
04
まとめ
05

View Slide

65
Copyright
まとめ
◼クラウドネイティブは非常にレイヤーが多く、跨ってのセキュリティ対応が必要で複雑化しがち
⚫ NRIはレイヤーごとにスタンダード、ベストプラクティスを取り込んでガイドラインを設定
⚫ ガイドラインを確実に適用するため、クラウド利用申請、適用審査、棚卸・年次調査、セキュリティ教育を実施
⚫ 利用者自身での定期診断が必須だが、手運用は負荷が高いため、ツールでの可視化・自動化を推奨
◼レイヤーごとに最適なツールをいれても、全体での整合性がつきにくい
⚫ 各ガイドラインを守るためのツールも、特定レイヤーに特化したものが多い
⚫ レイヤーを跨ったクラウドネイティブアプリケーションのライフサイクル全体のセキュリティ対策は道半ば
◼次の段階として、ライフサイクル全体を可視化するソリューションが求められる
⚫ CNAPPのような、これまでのクラウドネイティブセキュリティを統合した、包括的な取り組みが必要
⚫ 最適な解にはたどり着けておらず、NRIグループ全体で協力してSecurity Observabilityの実現を目指す

View Slide

View Slide

サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来

サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来

Shun Yoshie

More Decks by Shun Yoshie

Other Decks in Technology

Featured

Transcript