Oktaの「Secure by Design」誓約から1年

このブログはこちらの英語ブログ（2025年5月22日公開）の機械翻訳です。

はじめに

1年前、Oktaは米国サイバーセキュリティ・社会基盤安全保障庁（CISA）の7つの「Secure by Design」原則へのコミットメントを誓約した、最初のテクノロジープロバイダーのひとつでした。

CISAの功績により、「Secure by Design」誓約プログラムは、サイバーセキュリティ業界全体で大きな勢いを生み出しました。それ以来、約300社のテクノロジー企業がこの誓約に署名し、その多くがこれらの目標に向けた進捗を文書化する大きな前進を遂げています。

1年が経過した今、Oktaは進捗を振り返り、最新情報を共有します。

Oktaの「Secure by Design」への取り組みの一環として、すべての新しいOktaテナントのデフォルト設定は以下のように強化されました：

このSecure by Design誓約のもとで、OktaはCISAが特定した7つの重要分野において測定可能な改善に取り組むことを約束しました。

1. 多要素認証（MFA）の導入促進

誓約から1年以内に、メーカーの製品全体で多要素認証の使用を定量的に増加させるためのアクションを実施すること

Oktaは、Okta Workforce Identityのユーザーと管理者の両方において、MFA採用における業界最高水準の実績をさらに強化してきました。

この1年の誓約期間中、Oktaは次の3つの主要目標に取り組みました：

• Admin Consoleへのすべての管理アクセスに対してMFAを強制する
   
• Okta FastPassやFIDO2パスキーのような、高保証でフィッシング耐性のある認証器の迅速な採用を促進する
   
• より弱い認証方法への顧客依存を削減する
   

現在、Okta Admin ConsoleおよびAuth0 Management Consoleへのアクセスには、MFAが必須となっています。

この成果を達成するには、管理者が単一要素認証ポリシーを作成できないよう制限し、多くの顧客と連携して、施行前に既存ポリシーが要件を満たせるよう支援するという、大規模な取り組みが必要でした。

開始初期の段階で、いくつかの顧客には準備に時間が必要であることが判明しました。特に、インラインでのMFA登録を許可していたり、インバウンドフェデレーションを利用していたり、Okta Admin Consoleへのアクセスにサードパーティ製PAM（特権アクセス管理）ソリューションの特定構成を使用していたりする場合です。Oktaはこうしたケースに対応するために、認証器クレームの共有などの機能をリリースし、管理者の体験を損なわずにMFAを常に適用できるようにしました。ご対応いただいた顧客の皆様に、私たちの共通のセキュリティのためにご協力いただいたことを感謝申し上げます。

また、高保証でフィッシング耐性のある認証要素の急速な成長も確認されました。
Oktaの「Businesses at Work 2025」レポートによると、Okta FastPassによる認証の件数は12か月で377%増加しました。指紋や顔認証などの生体情報に裏付けられたFastPass認証の件数も288%増加しました。

対照的に、より低保証の認証方法の使用は減少しました：

• セキュリティ質問：12%減少
   
• SMS/音声通話：14%減少

2. デフォルトパスワードの使用削減

誓約から1年以内に、メーカーの製品全体でデフォルトパスワードの削減に向けた進展を示すこと

誓約期間の中間時点で述べたように、Oktaはデフォルトパスワードに関する追加対応は不要と判断しました。オンプレミスのアプライアンス、クライアント、エージェントがインストール時にデフォルト認証情報を必要とする場合、Oktaは初回サインイン時にこれらの資格情報の変更（ローテーション）を必須化しています。

3. よくある脆弱性クラスの削減

誓約から1年以内に、1つ以上の脆弱性クラスの発生率を顕著に減少させるための行動を示すこと

誓約開始時、Oktaは特定の脆弱性クラスの露出を削減する全社的なキャンペーンを開始することを約束しました。

まず、Oktaが開発する複数の製品とサービスにわたって、一貫した方法論で脆弱性を分類しました。

Okta Product Securityチームは、Auth0とOkta製品全体から脆弱性データを集約し、正規化・分析・分類された「単一の信頼できる情報源」を構築しました。

その結果、Bugcrowd VRTで「サーバーセキュリティ構成ミス」と分類される脆弱性のサブセットに特に注力すべきであることが明らかになりました。

このリストに載った脆弱性に対しては、コードベース全体を対象とした技術調査「ディープレビュー」を実施し、いくつかの問題点を特定・修正しました。

また、この取り組みの一環として、脆弱性クラスを削減するための手法を開発・共有しました。以下のフェーズで構成されています：

• データ分析：脆弱性情報の集約・分類・トレンド分析
   
• スコープ定義と計画実行：頻度とリスクに基づいて優先順位を付け、アクションプランを作成・追跡
   
• プログラムの改善：標準的なトレンド指標の導入、分類の標準化、フィードバックループの短縮
   

この手法は、CISAのSecure by Designワーキンググループとも共有されました。

4. 顧客によるパッチ適用の習慣改善の推進

誓約から1年以内に、顧客によるセキュリティパッチの適用率を定量的に向上させるための取り組みを実施すること

セキュリティにおける責任共有モデルにおいては、顧客がクライアントソフトウェアの最新バージョンを維持する責任を負っています。

CISAのSecure by Design誓約では、サービスプロバイダーがより積極的に関与し、顧客のパッチ適用の成果を支援する「運命共有（shared fate）」のアプローチを推進しています。

Oktaは、顧客がクライアントソフトウェアを常に最新の状態に保ちやすくすることに対する取り組みで、定量的な進展を遂げました。

この1年の取り組みの中で、OktaはAD（Active Directory）またはLDAPエージェントを、セキュリティ強化を含むバージョンへアップグレードするよう顧客に働きかけるキャンペーンを展開しました。

背景として、一部のOkta Workforce Identityの顧客は、一次認証をオンプレミスのADやLDAPディレクトリに委任しています。このようなハイブリッドアイデンティティフローでは、ユーザーがクラウドリソースへサインインする際の資格情報が、顧客ネットワーク上のホストで稼働するエージェントに送られ、認証されます。

この構成において、Okta実装の整合性はある程度、顧客のActive Directory環境の健全性に依存します。Okta Identity Defenceに報告されたインシデントの多くが、既に侵害されたActive Directoryネットワークに起因しています。

2024年7月、OktaはOIDCのDPoP（Demonstrating Proof of Possession）拡張を採用したADエージェントを再設計してリリースし、LDAPエージェントにも同様の保護を2024年11月に追加しました。DPoPはWindowsホストの侵害を直接防ぐものではありませんが、オンプレミスサーバーが侵害された際の被害範囲（blast radius）を大幅に縮小できます。

ADエージェントのリリースから90日以内に、顧客の44%がDPoP対応バージョンにアップグレードしました。その後、非対応バージョンのサポート終了を示唆するキャンペーンにより、導入率は83%に上昇。次のバージョンではエンドツーエンド暗号化もサポートされました。

さらに、顧客のパッチ適用習慣を改善する主要な手段として、「自動更新機能」の可用性と採用があることも確認されました。

エンドユーザークライアント向けのソフトウェアでは自動更新に対する抵抗は少ない一方で、サーバー側のクライアントソフトウェアでは自動更新に対する懸念が大きいこともわかりました。これは、他のベンダーでの障害事例に基づき、「更新がすべての顧客構成で適切にテストされているか？」というCISOの懸念があるためです。

この期間中、Oktaは安定したアップデート実績に関する直接的な情報提供キャンペーンを実施し、自動更新機能の導入率を6%増加させました。Oktaは今後も、顧客の信頼を高める新たな方法を検討し続けます。

5. 脆弱性開示ポリシー（VDP）の公開

誓約から1年以内に、公開されたVDPを整備し、善意のセキュリティ研究者による製品のテストを許可し、法的措置をとらないことを明言し、脆弱性報告チャネルを提供し、国際標準に従った公開開示を可能にすること

Oktaは誓約通り、すべてのGA製品に対して100%バグバウンティプログラムを適用し、脆弱性報告ポリシーと開示ポリシーを引き続き公開しています。

2024年5月〜2025年5月の間に、Oktaはバグバウンティ経由で提出された153件の有効な脆弱性をトリアージし、合計で405,801ドルの報奨金を支払いました。

この期間中、Oktaは「バウンティ報奨金の倍額・三倍額キャンペーン」を複数回実施し、特定製品における脆弱性の発見に対して高額報酬を提供しました。これにより新しいセキュリティ研究者が多数参加する結果となりました。

6. 脆弱性に関する透明性の提供

誓約から1年以内に、各CVEにCWEとCPEを正確に記載し、顧客によるパッチ適用が必要または悪用が確認された重大または高インパクトの脆弱性に対しては、適時にCVEを発行すること

Oktaはこの期間中、顧客に対する脆弱性情報の共有方法を正式化しました。

Okta製品で発見された脆弱性は、契約に基づいて修正対応を実施し、顧客側の対応が必要な脆弱性についてはCVEを公開します。OktaはCISAとMITREにより認定されたCVEナンバリング機関（CNA）であり、脆弱性情報をCVEとして公表する権限があります。

顧客がインストールするOktaクライアントやエージェントに関するCVEはオンラインで公開されています。

また、Oktaはより広範な脆弱性タイプに対しても通知プロセスを改訂し、すべての報告は技術的評価と顧客影響評価の両面から検討されます。

7. 顧客向けのログ記録と監視機能の向上

誓約から1年以内に、メーカー製品に対するサイバーセキュリティ侵害の証拠を顧客が収集できる能力を定量的に向上させること

Oktaのすべての製品には、管理者がアクセス問題をトラブルシュートし、セキュリティチームが不審な活動を監視するための仕組みが備わっています。

最小限でも、ログイベントには認証、アプリケーションアクセス、管理者・ユーザー操作、セッションコンテキスト、アクションの送信元・対象情報が含まれます。詳細は半年時点のアップデート表を参照ください。

誓約期間中、OktaはOktaとAuth0の両プラットフォームに対してログ改善を実施しました。以下に要点をまとめます。

Okta System Logの改善：

Auth0 System Logの改善：

結び

CISAのSecure by Design誓約に署名した瞬間から、Oktaのプロダクト、エンジニアリング、セキュリティチームはこの重要な仕事に取り組むことに熱意を持っていました。この誓約は、Oktaの4つの中核バリューの1つ「Always Secure, Always On」と強く一致しています。そして、Oktaのすべての従業員が、Okta Secure Identity Commitment（アイデンティティ攻撃と戦うための長期的イニシアチブ）のもとで、セキュリティへの貢献を奨励されています。

CISAのアプローチで優れていた点の1つは、署名者に対して進捗の証明を求めたことです。これにより、既に成熟している分野でも、さらなる改善の努力が奨励されました。

最も難しかった議論の1つは、各プログラムにおける「完了の定義」でした。あらゆるコントロールのカバレッジの最後の5〜10%を完了させるには、最初の90〜95%を超えるリソースが必要であることが分かりました。例外処理のサポートや特殊なユースケースの対応には、特に多くの負担がかかりました。

それでも、私たちが掲げた野心的なマイルストーンに対して、Oktaの社員が協力し合い、譲歩し、イノベーションを起こしてくれたことを、私は非常に誇りに思っています。

誓約の中間報告でも述べましたが、Secure by Designに「完了」はありません。Oktaは、特にすべてのクラウドアプリケーションがサポートすべきセキュリティ機能について情熱を持っています。そして、Oktaの最も大きく、野心的な目標であるアイデンティティベースの攻撃の排除に向けて前進し続けます。

以上の内容は、原文（英語）の機械翻訳であり、原文と内容に差異がある場合は、原文が優先されます。