【Oktane25】セッションレポート：Okta社が実践するセキュアな従業員オンボーディングとゼロトラスト環境

では、具体的にどのような脅威がオンボーディングプロセスを狙っているのでしょうか。セッションで提示されたスライドを基に、特に注意すべき脅威をカテゴリー別に見ていきましょう。

1. ID盗用となりすまし (ID theft & impersonation)
国家レベルの脅威： スライドにFBIの指名手配書が示されているように、某国の工作員が偽の身元でITワーカーになりすまし、企業へ潜入しようとする組織的な攻撃が存在します。

偽のプロフィール作成： スライドの画像にもあるように、AIが生成した顔写真やストックフォトが悪用され、本物と見分けがつきにくい偽の職務経歴書（レジュメ）が作成されます。

巧妙な分業体制： 中には、「応募する人物」「面接を受ける人物」「実際に出社して働く人物」がそれぞれ別人という、悪意のある分業体制で企業を騙すケースも起こり得ます。

2. アカウント乗っ取り (Account takeover)
正規の従業員アカウントが乗っ取られる脅威です。新入社員がフィッシングメールや悪意のあるウェブサイトなどを誤ってクリックすることでアカウント情報が盗まれ、攻撃者が正規従業員として社内システムへ侵入することが可能になります。

3. サプライチェーン攻撃 (Supply chain attacks)
サプライチェーン攻撃も脅威として挙げられており、スライドでは**「ベンダー → ソフトウェア → 顧客」**へと連鎖する攻撃経路が示されています。これは、取引先や利用ツールを踏み台に、最終的な標的である企業へ侵入する手口です。

4. 内部脅威 (Insider threat)
スライドでは**「Pay for Access」**と表現されているように、従業員が金銭と引き換えに意図的にアクセス権限を第三者に提供するなど、悪意を持った内部関係者による脅威も深刻です。

5. AIによる脅威（ディープフェイク）
AIで精巧に作られた偽の音声や映像（ディープフェイク）を利用し、ビデオ面接などで本人になりすます**「大規模な音声・ビデオ詐欺」**です。これはリアルタイムで行われることもあり、実際に数百万ドル規模の金銭的被害も報告されています。

6. 信頼性の高い役割（High-trust roles）に対するリスク
管理者権限を持つような特に信頼性が高い役割の従業員に対しては、一度きりの本人確認だけでは不十分です。スライドで示されている通り、身元調査（BG checks）、グローバルIDチェック、ジャストインタイム（JIT）アクセスといった、継続的な検証が不可欠となります。

これらの脅威は、もはや他人事ではありません。では、こうしたリスクにどう立ち向かえばよいのでしょうか。次章では、その設計思想となるゼロトラストの考え方について解説します。

Oktaが実践するゼロトラストセキュリティアーキテクチャ

前章で見たような巧妙な脅威に対抗するための設計思想が「ゼロトラスト」です。その原則はシンプルで、**「決して信頼せず、常に検証する (Never trust, always verify)」**という考え方に基づきます。

この概念を実際のアーキテクチャに落とし込んだのが、スライドで示されている構成です。中央に位置する**Oktaを「ゼロトラストの制御プレーン（Control Plane）」**として、すべての要素を連携させる頭脳として機能させます。このアーキテクチャは、主に4つの柱で構成されています。

1. ユーザー保証 (User Assurance)
まず基本となるのが、リソースにアクセスしているのが本当に「本人」であるかを確かめることです。

Oktaの役割：
　ID管理（Identity Administration）や時間ベースのアクセス制御を行います。
連携パートナー：
　Persona: 本人確認（Identity Verification）を行い、ユーザーが申告通りの人物であることを保証します。
　YubiKey / Okta FastPass: ハードウェアキーと組み合わせることで、フィッシング耐性の高い強力な認証を実現します。

2. デバイス保証 (Device Assurance)
次に、ユーザーが使用しているデバイスが信頼できるものであることを検証します。認証されたユーザーであっても、侵害されたデバイスからのアクセスは重大なリスクとなるためです。

Oktaの役割：
　Okta Verifyによるデバイス状態（Posture）のチェックを行います。
連携パートナー：
　Jamf / Microsoft Intune: MacおよびWindowsデバイスを管理し、セキュリティポリシーを適用します。
　CrowdStrike: デバイスのセキュリティ状態をチェックし、その情報をOktaに提供します。
　Okta FastPass: 強力なフィッシング耐性を持つデバイスIDを確立します。

3. コンテクスチュアルアクセス (Contextual Access)
ユーザーとデバイスの情報を統合し、アクセス時の「状況（コンテキスト）」に応じて判断を下します。

Oktaの役割：
　場所やふるまい検知といったシグナルを利用し、リスクが高いと判断した場合に追加認証を要求するアダプティブMFA（多要素認証）や、リスクベースのポリシーを適用します。
連携パートナー：
　Prisma Access (Palo Alto Networks): ネットワークの検証シグナルを提供します。
　CrowdStrike: エンドポイントのセキュリティ情報を提供します。
　Chrome Enterprise: ブラウザのセキュリティシグナルを共有します。

4. セキュリティインサイト (Security Insights)
アーキテクチャ全体から収集したシグナルを集約し、セキュリティの監視と態勢管理に活用します。

Oktaの役割：
　ISPM (Identity Security Posture Management) 機能により、IDセキュリティの状態を可視化・管理します。
連携パートナー：
　Splunk / CrowdStrike (XDR): OktaからのシグナルをSIEMやXDRに取り込み、組織全体の脅威検知と対応に役立てます。

このように、Oktaを頭脳としてセキュリティスタック全体からシグナルを収集し、連携させることで、よりスマートで安全な意思決定を下すことが可能になります。

※SWGとして紹介されているPrisma Accessは勿論弊社が取り扱う「Netskope」でも実装可能です！！

このアーキテクチャを基に、実際のオンボーディングはどのように行われるのでしょうか。次章では、具体的な実践ロードマップを見ていきます。

Day 0からの保護 - セキュア・オンボーディング実践ロードマップ

第2章で解説したゼロトラストのアーキテクチャは、具体的にどのようなプロセスでオンボーディングに適用されるのでしょうか。この章では、Oktaが実践する具体的なロードマップを、スライドで示されている「Secure Onboarding Checklist」の3つのフェーズに沿って解説します。

フェーズ1：本人確認 (Identity Proofing) - 採用候補者は実在するか？
　最初のステップは、候補者が履歴書の外に実在し、信頼できる人物であることを確認することです。

①存在のチェック (Check if the identity exists):
　スライドでは「OSINT（オープンソース・インテリジェンス）」が挙げられていますが、これは提供された身元情報が実在する個人ものであるかを判断するプロセスです。

②バックグラウンドチェックの実施 (Confirm background details):
　候補者の経歴に偽りがないかを確認するため、身元調査を行います。

フェーズ2：ID検証 (Identity Verification) - 提示されたIDは本物か？
　次に、候補者が提示した身分証明書が本物であり、かつ本人が正当な所有者であることを検証します。

③所有権の検証 (Validate ownership of identity):
　提示された身分証明書を本人が正当に所有していることを確認します。この目的でPersonaというツールが使用され、候補者は政府発行の写真付きIDの写真を撮り、自身の顔をスキャンする必要があります。

④文書の信頼性チェック (Check document authenticity):
　（候補者が面接に合格し入社を受け入れた場合）スライドにある通り、検証サービスを活用して、提出された書類が本物であることを確認します。身元調査がクリアされると、事前登録されたYubiKeyが個人の住所に送付され、PINが個人のメールアドレスに送信されます。

⑤対面でのオンボーディング (In-person onboarding):
　新入社員は全員がOktaのオフィスで対面によるオンボーディングを完了させます。この際、郵送されたYubiKeyやPINおよび政府発行の身分証明書を持参させ、本人確認を厳重に行います。加えて事前に実施したPersonaでのID確認を改めて出社時に実施します。



フェーズ3：ID認証 (Identity Authentication) - アクセスしているのは本人か？
対面での厳格な本人確認が完了すると、いよいよアカウントへのアクセスです。ここでもゼロトラストの原則が徹底されます。

⑥アカウント所有者の検証 (Verify the account owner):
　アカウントへの最初のログインは、持参したYubiKeyとPINを使って行われます。これにより、初回のアクセスからフィッシング耐性の高い多要素認証（MFA）が強制され、アカウントが発行された瞬間からセキュアな状態が保たれます。この一連のステップにより、**「応募し、面接を受け、初日に出社した人物が、すべて同一である」**という確信が得られます。

⑦コンテクスチュアルアクセス (Contextual-based access):
　スライドにある通り、デバイスのシグナル、ネットワーク情報、そしてUEBA（ユーザーの行動分析）といったコンテキスト情報を活用します。これにより、リスクが高いと判断された場合にアクセスをブロックしたり、追加認証を要求したりできます。

継続的な監視：
　オンボーディング後も、CrowdStrikeのようなツールと連携してデバイスの状態を監視し、安全でないと判断されればアクセスを拒否します。

このロードマップを通じて、Oktaは「応募した人物、面接した人物、そして初日に出社した人物がすべて同一である」という信頼を確立しています。次章では、このプロセスを実践する上での課題と、それに対する解決策を見ていきましょう。

セッション中のQ&Aまとめ

最後にセッションで取り上げられたQ&Aをご紹介します。

Q1. セキュリティと利便性（手間）のバランスはどう取っていますか？
A1. 専門のサポートチームを設け、ユーザーを支援するためのトレーニングや記事を充実させています。その上でツールを最適化し、セキュリティを強力かつシームレス（目に見えない形）に保つことで両立しています。

Q2. GDPRなどのコンプライアンスはどのように確保していますか？
A2. 事業を展開する全ての国で利用が許可されたツール（例：Persona）を選定し、さらに各国の規制を法務チームが個別に確認することで遵守しています。

Q3. 全てのユーザーに同じレベルの本人確認を適用すべきですか？
A3. はい。ゼロトラストの原則に基づき、**「全員を検証する」**ことが基本です。継続的な本人確認と、役割に応じた最小権限アクセスを組み合わせることで、組織全体の安全を確保します。

Q4. 契約社員やコンサルタントにはどう対応しますか？
A4. 対面での確認が難しい契約社員などには、採用プロセスの最初期にリモートでのID検証を実施します。その後も面接やオファーの段階で複数回本人確認を行うことで、一貫して同一人物であることを保証します。

Q5. YubiKeyのPINを個人のメールアドレスに送るのは安全ですか？
A5. 安全です。PINは認証に必要な要素の半分に過ぎず、物理的なYubiKey本体がなければ意味をなさないため、PIN単体が漏洩しても不正利用にはつながりません。

おわりに