皆様こんにちはこんばんは、Oktaneをこよなく愛するネクストモードのおはらふです
Oktaが普段我々に見えない部分のセキュリティをどう構築しているか、その考えも含めたセッションがありましたので、その様子をお届けしたいと思います
Oktane25、STRIDE Framework、イノベーションとセキュリティ、 証明書管理
前半後半の2部構成に分かれており、それぞれの話者は次のとおりでした
AI駆動の脅威モデリング：Arun Kumar Elengovan
現実世界の証明書管理：Nandagopal Seshagiri
このセッションも、機能性（イノベーション）とセキュリティというトレードオフについて、Oktaがどう戦っているか？といった内容も含んでいるよ。と導入がありました
前半のテーマはAIを使った脅威モデリングのセッションです
ところで皆様は「マイノリティリポート」という映画を見たことあるでしょうか？
—
3人の「予知能力者」たちを使った殺人予知システムが実用化された近未来。予知された殺人犯（未来犯罪者）を未然に逮捕、拘禁する犯罪予防局の設立から6年が経過した西暦2054年のワシントンD.C.の殺人発生率は0%になったと報告されていた・・・『出典：Wikipedia』
といった世界観の映画で、今の現実世界ではマイノリティリポートでいう「予知能力者」が「AI（脅威モデリング）」に置き換わった世界が描けるとのことです
OktaがAIを駆使した脅威モデリングを使って、脅威が起きる前に阻止しようとする仕組みをどう構築しているかの話に繋げていました
ちなみに、脅威モデリング（Threat Modeling）というのは、システムやサービスに潜む「どんな攻撃がありうるか」「その攻撃に対してどこが弱点になるか」を体系的に洗い出して整理するプロセスのことです
従来型脅威モデリングの問題は、遅い（手作業）、スケールしない、主観的で一貫性がないため、「従来の脅威モデリング」から「AIアシストの脅威モデリング」へ移行を考えたとのことです
うまくいくためのシンプルな戦略を4段階で整理し、それを学びとして共有しています
1）コンテキスト対応の知性（RAG、LLM)
2）プロンプト設計（マルチバリアント）
3）マルチモーダル分析能力（アーキテクチャやデータフロー図の理解）
4）対話型ワークフロー
Oktaはこの4つの機能を合わせて、AIアシストな脅威モデリング運用を構築しています
脅威データの履歴、既知の脆弱性、イメージの理解、そして組織的記憶（これが今や非常に重要）を取り込みます
脅威モデリングのフレームワークのひとつに、マイクロソフトが提唱しているSTRIDEフレームワークがあります
6つの脅威の頭文字を取った名前になっており、それぞれの意味は下記のとおりです
S – Spoofing（なりすまし） 正規ユーザーやサービスになりすます脅威 例：攻撃者が他人のID/パスワードを盗んでログインする
T – Tampering（改ざん） データやコードを不正に変更される脅威 例：通信途中でメッセージを改ざんする（Man-in-the-Middle攻撃）
R – Repudiation（否認） 行為を「やっていない」と言い逃れできる脅威 例：ユーザーが不正送金した後に「自分じゃない」と主張する
I – Information Disclosure（情報漏洩） 秘密情報が漏れてしまう脅威 例：暗号化されていないファイルを外部に盗まれる
D – Denial of Service（サービス拒否） サービスが利用できなくなる脅威 例：DDoS攻撃でWebサイトが落ちる
E – Elevation of Privilege（権限昇格） 本来持たないはずの権限を手に入れる脅威 例：一般ユーザーが管理者権限を奪取する
AIを既存のモデルに追加の層として重ねることが重要であり、フィールド（現場）から切り離さないことがポイントと述べていました
最後の重要な基礎要素として、「人間要素」が不可欠です
スピードと網羅性、重労働の肩代わりをAIにやらせつつ、最終決定権は人間が持つ
私からの締めの言葉はこうです——AIは副操縦士（コパイロット）だが、機長はあなた
操縦桿を握るのはあなたです
と前半部分のセッションが終了しました
後半のテーマは現実世界の証明書管理についてです
サブタイトルにFrom Long-Lived to Ephemeral (with trust agility) とあるように、長期利用前提の証明書運用から、より寿命の短い証明書運用をどうスピード感と信頼性を担保しつつ実施していくかの話となります
前半はAIでリスク管理を行う話でした
後半では具体的に証明書関連が標的になった場合どう対応すべきか？といったテーマから話が進んでいきます
「証明書を管理するのではなく、“信頼（Trust）”を管理せよ」
このアプローチが、大半のリスクに効くと考えていると熱弁していました
分散IDとクレデンシャル管理により、暗号アルゴリズムの変更や信頼関係切替の俊敏性も高まり、必要に応じて動的な認証・認可の設計も可能となります
一方でこれらを実運用で実現することは難しいと課題提起しています
サービスメッシュにより解決済みでは？という問いに対しては、サービスメッシュに対する保護は行われるものの、メッシュの外に対しても意識を向けるべきと答えます
マルチクラスタ／マルチクラウド、VM・ベアメタル・サーバーレス、サードパーティSaaSのAPI、ハードウェアモジュールやガバナンス
さまざまなコンポーネント証明書が絡む現実では、問題はまだ解き切れていません
そこで、Webスケールで証明書運用を自動化する要点を整理しています
ディスカバリの具体策としては、まずソースコード検索（PEMや設定値の横断検索）が有効です
次にCMDB／資産台帳で「どのアプリが何を使うか」を突き合わせ、チケットから更新やローテーションの兆候を拾います。こうして作った完全なインベントリは、新しい管理システムへの移行時にも役立ちます
証明書の発行・保管にはAWS Private CAや各クラウドの証明書管理サービスが使えます。大事なのは可用性・レジリエンス・運用の容易性です
外部公開用のサーバー証明書を第三者の認証局（CA）で発行する場合は、エージェントによる自動ローテーションを行うのが望ましいでしょう
また、トランザクション用途での鍵操作については、各クラウドが提供する KMS（Key Management Service）を利用するのが安全で確実です
「Root of Trust」の設計も重要なポイントです
中間CAはオンライン運用にして、自動化や省力化を進めるのが一般的です
一方でルートCAは、原則としてオフラインに保管するのが望ましい
ここまで整えても、現場ではひと手間が残ることがあります
全てのアプリがダウンタイム無しでの証明書更新に対応しているわけでもなく、レガシーなシステムでは再起動が前提だったりします
アプリごとに更新サイクルも違う。なので、既存のパッチ適用やバージョンアップの計画に便乗して組み込むのがコツです
場合によっては最初は長寿命証明書で始め、小刻みに短寿命化へ寄せていく。それで構いません。漸進こそ鍵だと述べています
改めて登場するのが Root of Trustです
従来型のモデルや、インフラをすべてコンテナ化した“半・従来型”モデルでは、ある程度効率化はできても、環境ごとに信頼（Trust）を配布・更新していくコストは依然として高止まりしています
そこで提案するのが、「信頼（Trust）をインフラ層で扱う」という考え方です
すなわち Externalized Trust（信頼の外部化）
インフラが全体を覆う「信頼のレイヤー」を提供し、アプリケーションはその信頼（Trust）を消費するだけで、自ら抱え込む必要はありません
これにより、管理対象は証明書そのものではなく、「信頼（Trust）」そのものになります。そして可能な限りの俊敏性を持って運用できるようになるとのことです
最後にまとめがありました
このセッションでは主にインフラにおける「見えないセキュリティー」の二本柱を扱いました
AIを使った脅威モデリング
アイデンティティのための証明書管理
脅威モデリングはAIでカバレッジと速度を、証明書は「信頼（Trust）を管理する発想」で運用を極小化できます
Okta社による2つのセキュリティトピックの裏側（AIを駆使した脅威モデリング構築、証明書管理）について学べるだいぶ濃いセッションでした
過去に色々あったOkta社ですが、その教訓を忘れず裏側では様々な取り組みを実施していることが分かるテクニカルなセッションでお腹いっぱいになれました