【Oktane25】セッションレポート：OktaとPalo Alto Networksが示すゼロトラストへのアプローチ

ブラウザセキュリティが必要な背景＋解決策

セッションは、現代の働き方が直面する3つの課題から始まりました。

1. 従業員は、あらゆるデバイスから、あらゆる場所で仕事をしている

2. 生産性とセキュリティを両立させる必要がある

3. AIの活用が、新たな脅威とデータ漏洩のリスクを生んでいる

特に、今日の業務はブラウザ中心で行われており、従業員の労働時間のうち85〜100%がブラウザ内で費やされています。しかし、そのブラウザがセキュリティの脆弱点となっています。実に90%の組織が従業員による管理外デバイス（個人所有デバイス）からのアクセスを一定程度許可しており、ランサムウェア侵害の約90%がこれらの管理外デバイスから発生しているというデータが示されました。

この課題に対し、OktaとPalo Alto Networksの連携は、運用コストを33%削減し、ROIを122%向上させるという具体的な価値を提供しているとスピーカーは語ります。

解決策（連携例①）：Okta + Prisma Access Browserによるアクセス制御

課題に対する具体的な解決策の1つ目が、Palo Alto Networks社のセキュアブラウザ「Prisma Access Browser」とOktaの連携です。

Prisma Access Browserは、ChromeやEdgeと同じChromiumベースで開発されており、ユーザーは違和感なく利用できます。その上で、管理外デバイスからのアクセスであっても、企業が求める厳格なセキュリティポリシーを適用できるのが特徴です。

セッションでは、「Akira」というアカウントを例にしたデモが行われました。

デモ：Okta×Prisma Access Browserで管理外デバイスからのアクセスを制限する

1. 「Akira」が管理外デバイスの通常ブラウザでOkta経由でSalesforceにアクセスしようとします。

2. Oktaのポリシーが作動し、「この操作を実行する権限がありません。Prisma Access Browserを使用してください」というエラーメッセージが表示され、アクセスはブロックされます。
   

3. 「Akira」は指示通りPrisma Access Browserに切り替えます。ブラウザ自体のロックを解除するためのPIN認証などを経て、Oktaにログインします。

4. 今度は正常に認証が完了し、Salesforceにアクセスできました。しかし、アクセス後もPrisma Access Browserはデバイスの状態をチェックし続け、画面右側には「デバイス証明書がない（管理外デバイスである）」といったデバイスの状態（ポスチャー）情報が表示されます。
   

5. 「Akira」がSalesforce内の機密情報（クレジットカード番号）をコピーし、ChatGPTに貼り付けようとすると、Prisma Access BrowserのDLP（情報漏洩防止）機能が作動。「機密データが検出されました」という警告と共に、ペースト操作をブロックしました。
   

このように、OktaとPrisma Access Browserを連携させることで、デバイスの状態に関わらず、誰が、どのデバイスから、どのアプリケーションにアクセスし、どのような操作を行っているかをきめ細かく制御できるようになります。]

連携例②：Okta ＋ Cortex XDRでリアルタイムセッション監視

2つ目の連携として、脅威検知とリアルタイムの対応に関するデモが紹介されました。これは、OktaのIdentity Threat Protection (ITP)× Palo Alto NetworksのCort XDRの連携例となります。

Okta ITPは、Okta自身の持つIDに関するシグナルと、Palo Alto Networksのような外部セキュリティ製品からのシグナルを統合し、継続的にリスクを評価。その評価に基づいて、リアルタイムに「セッションの強制ログアウト」や「追加のMFA要求」といったアクションを自動で実行するものです。

デモ：リアルタイム脅威対応によるセッションの強制ログアウト

1. あるユーザーが、フィッシングメールから悪意のあるファイルをダウンロードしてしまいます。

2. エンドポイントで稼働しているPalo Alto NetworksのCortex XDRが、この悪意のあるアクティビティを即座に検知・ブロックします。

3. 同時に、Cortex XDRはOktaに対して「このユーザーは危険な状態にある」というリスクシグナルを送信します。

4. シグナルを受け取ったOktaは、事前に設定されたリスクポリシーに基づき、即座にそのユーザーの全てのセッションを強制的にログアウトさせ、被害の拡大を防ぎます。

この一連の流れは、Okta管理管理コンソールで「高リスクを検知したら、ログアウトしてトークンを無効化する」というポリシーを設定しておくだけで、完全に自動化されます。これにより、管理者がインシデントに気づくより早く、システムが自律的に防御アクションを取ることが可能になります。

お客様事例：Kyndryl社とのQ&A

2つ目の連携として、脅威検知とリアルタイム

セッションの最後には、実際にOktaとPalo Alto Networksを導入しているKyndryl社のJohn氏が登壇し、Q&A形式でその経験を共有しました。

Q1. ITP導入の背景にあるセキュリティ戦略は？

A. 我々はIBMからスピンオフして以来、技術的負債の解消を進めてきました。現在の戦略は、事後対応から事前対応（プロアクティブ）への移行です。IDを起点とした最小権限の原則を徹底し、好ましくない振る舞いを早期に検知・対応することを目指しています。

Q2. なぜOkta ITPを選んだのですか？他の製品は検討しましたか？

A. 他の製品は一切検討しませんでした。 我々はOktaと素晴らしい関係を築いており、ITPはその自然な拡張でした。特に、Oktaが持つ全顧客から得られる広範な脅威インテリジェンスを活用できる点が、自社単独では得られない「戦力増強効果」として非常に魅力的でした。POC（概念実証）も数時間で価値を証明できたため、導入は「考えるまでもない」決定でした。

Q3. 導入はどのように進めましたか？

A. まずは監視モードで導入し、自動的なアクションは有効にしませんでした。どのようなイベントがリスクとして検知されるかを数週間にわたって分析し、自社の環境に合わせてチューニングを行いました。ビジネスプロセスを壊さないように慎重に進め、現在は中程度のリスクについても分析を進めている段階です。

Q4. 今後、どのような成果を期待していますか？

A. ITPから得られるインサイトを活用し、リスクレベルに応じた委任されたワークフロー（Delegated Workflows）を構築したいと考えています。標準のアクションをそのまま使うのではなく、自社のビジネスを壊さずに脅威を修復できる、より具体的なアクションを自動化していくことが目標です。

おわりに