Oktaのセキュアバイデザインへの継続的な取り組み
このブログはこちらの英語ブログ(2024年10月31日公開)の参考和訳です。原文と内容に差異がある場合は、原文が優先されます。
はじめに
2024年5月、OktaはCISAセキュアバイデザイン誓約に署名した最初のテクノロジー プロバイダーの1社となりました。この誓約では、エンタープライズソフトウェア企業が1年以内に7つの高レベルのセキュアバイデザイン目標を達成するために「誠意を持って」努力することを約束しています。
このブログでは、この誓約に対するOktaの進捗状況をお伝えします。
当初、これらの目標を達成することは難しくないと考えていました。しかし、当社の製品と業務の100%で例外なくこれらの目標を達成することを約束することは、想定以上に困難であることがわかりました。例外となるエッジケースを探し出し解決策を設計することは、重要な作業です。
目標 |
2024年10月時点の進捗 |
多要素認証の導入を推進 |
進行中 |
デフォルトパスワードの利用を削減 |
完了 |
脆弱性クラスの削減 |
進行中 |
お客様のパッチ適用プロセスの改善 |
進行中 |
脆弱性開示ポリシーの公開 |
完了 |
脆弱性の透明性の提供 |
完了 |
お客様向けのログ記録と監視を改善 |
進行中 |
技術的には取り組みの中間点にいます。しかし、セキュリティのベストプラクティスに対するOktaの取り組みは、取り組みから1年経過する2025年5月が過ぎても終了するわけではないことを強調したいと思います。Okta は、アイデンティティベースの攻撃との戦いで業界をリードするための長期的な取り組みに取り組んでいます。これを Okta Secure Identity Commitment と呼んでいます。
その点を踏まえると、CISAが目標リストを拡大し、「Secure by Design」を複数年にわたるプログラムにすることに反対するつもりはありません。Oktaでは、企業におけるアイデンティティの新しいオープンスタンダードであるIPSIEを通じて、新たな脅威に対処するためにエンタープライズアプリケーションに導入する必要があるセキュリティ機能について大きなアイデアを持っています。CISAや業界パートナーと協力して、クラウドサービスの回復力と安全性を向上する未来を築く準備はできています。
1. 多要素認証の導入を推進
「誓約書に署名してから1年以内に、メーカーの製品全体で多要素認証の使用を大幅に増やすために講じた措置を実証してください。」
現状
多要素認証は、最も費用対効果が高く、普遍的に適用可能なセキュリティ制御の 1 つであることが証明されています。
Okta は、Workforce Identity Cloudのユーザーと管理者の両方において、多要素認証の採用の高い実績を誇っています。当社は、The Secure Sign-in Trends Reportを通じて、MFAの採用、使用、パフォーマンスに関する統計を公開しています。このレポートには、MFAの総使用と特定のAuthenticator使用の相対的な増加と減少が記録されています。
2024年1月現在、Okta Workforce Identity Cloudの管理者の91%とユーザーの66%が多要素認証を使用してアプリケーションにサインインしています。これは、COVID-19渦の数か月前と比較し、 MFAの使用がほぼ2倍になったことを示しています。
Workforce Identity Cloudでサポートされている、パスワードレスでフィッシング耐性のあるサインイン方法 (Okta FastPassとFIDO2 WebAuthn) は、2024年1月の時点で最も急速な成長を記録しました。Okta FastPassの成長は最も印象的で、この認証方式は、2022年末にはユーザーの2%であったところ、2024年1月にはユーザーの6.4% (および管理ユーザーの13%) に増加しました。
Okta が歴史的に、自発的なMFA導入の点で業界を上回ってきた理由はいくつかあります。
- OktaはすべてのユーザーがMFAにアクセスできるようにしました。
- 2022年にリリースされたOkta Workforceプラットフォームの最新バージョンであるOkta Identity Engineでは、すべてのお客様が複数のサインイン方法 (Okta Verify OTPとOkta FastPass) を利用できます。これらのMFAは、お客様がOkta MFAソリューションのライセンスを取得しているかどうかに関係なく、2番目の要素として使用できます。
- Oktaはパスワードレス認証の採用を推進しています。
- Okta Identity Engineは、従業員のアプリケーションへの安全なアクセスのために、パスワードレス認証フローを可能にするポリシーエンジンです。これにより、組織は、最新デバイス上の特定のユーザーグループに対して、パスワードの使用を段階的に廃止できるようになります。
- 2024年2月以降、FIDO2パスキーはOkta Customer Identity Cloud (Auth0) の最上の認証要素となり、消費者向けアプリや Webサイトでパスワードに代わる新しい認証手段をお客様に提供できるようになりました。
過去18か月間、OktaはMFAの導入を促進するためにいくつかの取り組みを行ってきました。
- Oktaは、より強力なサインインフローをお客様に推奨するために、Workforce またはCustomer Identity Cloudの新しいテナントで SMSをデフォルトのMFA方法として提供することを停止しました。
- Oktaでは、管理者がOkta Admin Console (Workforce Identity Cloud) または Auth0 Admin Console (Customer Identity Cloud) へのアクセスに対して単一要素の認証ポリシーを作成することはできなくなりました。
- お客様の管理者は、Workforce Identity Cloudのお客様向けのサービスデスク/サポートアプリケーションであるOkta Help CenterにアクセスするためにMFAが必要になります。
目指すべき状態
Oktaの目標は、セキュアバイデザイン誓約の期間内に、インターネット接続サービスへのすべての管理アクセスに対してMFAを実施することです。
Okta Admin ConsoleのMFA実施プログラムは 2024年9月に開始され、2025年3月までに完了する予定です。
このプログラムは複雑で、フェデレーションIDプロバイダーや特権アクセス管理ソリューションの使用など、Oktaのお客様が特権アカウントにアクセスするために使用するさまざまなメカニズムをサポートするように段階的に推進しています。
日付 |
実施施策 |
2024年8月 *完了* |
Okta管理者は、Okta Admin Consoleへのアクセスに対して単一要素認証ポリシーを作成できなくなりました。 また、MFAの適用スケジュールが通知されました。 |
2024年9月 *完了* |
本番テナントのOkta Admin ConsoleへのアクセスにMFAが必須となります。 次のテナントは一時的にMFAの強制を免除されます: (a) インラインMFA登録を許可していない(b) インバウンドフェデレーションを使用している(c) PAMソリューションを使用してOkta Admin Consoleにアクセスしている |
2024年 11月 |
インラインMFA登録を許可していないテナントを含む実稼働テナントの Okta Admin ConsoleへのアクセスにMFAが必須となります。 |
2025年 1月 |
サードパーティ統合の構築に使用される開発者テナントのOkta Admin Consoleへのアクセスに、MFAが必須となります。 |
2025年 3月 |
Okta Admin ConsoleへのすべてのアクセスにMFAが必須となり、フェデレーションやPAMソリューションを利用している場合を考慮するためにAMRクレームマッピングを使用します。 |
Oktaの長期的な目標は、すべての管理アクセスに対して、パスワードレスでフィッシング耐性のある認証が採用されることを促進することです。このサインイン方法により、最も一般的な形態のアイデンティティベースの攻撃にさらされる可能性が大幅に減少します。
現在の取り組みは次のとおりです。
- Okta Admin Consoleにサインインした管理者に対し、フィッシング耐性のある認証要素の登録をアプリ内通知にて推奨
- Admin Consoleのダッシュボードで、フィッシング耐性のある認証の適用状況を可視化
- 管理者とエンドユーザーのフィッシング耐性のある認証の導入率を追跡する、The Secure Sign-in Trends Reportの更新。
当社のもう1つの主要な取り組みは、登録から認証、回復まで、ユーザーのライフサイクル全体にわたってフィッシング耐性を拡張する追加機能の導入です。これには、ユーザーのオンボーディングを保護するための事前登録済みのFIDO2セキュリティキーや、政府発行の文書を使用してユーザーのアイデンティティを確認するために使用できる本人確認ベンダー(IDV)との統合が含まれます。
2. デフォルトパスワードの利用を削減
誓約書に署名してから 1 年以内に、メーカーの製品全体でデフォルトのパスワードを削減するための測定可能な進捗状況を示します。
現状
デフォルトのパスワードは、回避可能なセキュリティリスクをもたらします。
Oktaクラウドサービスで生成されるすべてのシークレットはランダムに生成されます。これには、顧客テナントの暗号化キー、アプリケーション統合用のクライアント シークレットまたはJWKキーペア、一時的なユーザーパスワード、APIキーが含まれます。
オンプレミスのアプライアンス、クライアント、またはエージェントがインストール時にデフォルトの認証情報を必要とする場合は、OktaはAdmin Consoleへの最初のサインイン時にこれらの認証情報のローテーションを強制します。
目指すべき状態
すぐに実施しなければならない追加施策はありません。
3. 脆弱性クラスの削減
誓約書に署名してから1年以内に、製造元の製品全体にわたって1つ以上の脆弱性クラスの蔓延を大幅に測定可能な形で削減することを目指して講じた措置を実証します。
現状
Oktaの製品セキュリティ チームは、すべてのOkta製品に対してセキュリティテストを実行し、サードパーティから提出された脆弱性レポートをトリアージします。
継続的な改善のため、チームはWorkforceとCustomer Identity Cloud全体で報告された脆弱性の大規模な調査を実施しています。最新の調査では、このデータを Bugcrowd Vulnerability Rating Taxonomy (VRT) に対して正規化し、時間の経過とともに報告された重大かつ高レベルの脆弱性に関する傾向指標を生成しました。
Okta製品セキュリティチームは、この分析の出力を使用して、脆弱性の最も一般的な根本原因に対処するために必要なツール、プロセス、キャンペーンに関する決定を下します。
Oktaセキュリティ教育担当部署は、調査結果を使用して、たとえばトレーニングや意識向上キャンペーンの重点分野を開発します。一方、Oktaセキュリティレビュー担当部署は、定期的に繰り返し発生するバグクラスの「詳細なレビュー」を行い、多数の開発チームでそのバグの発生を防ぐ方法について推奨事項を作成します。
このフィードバックループにより、Okta製品のさまざまな脆弱性がほぼ根絶されました。その一例が、サーバーサイドリクエストフォージェリ(SSRF)です。Oktaのセキュリティエンジニアリング部門は、複数回の徹底的なレビューを経て、2020年に SSRF保護メカニズムを書き直しました。それ以降の3年間で、発見されたSSRFバグの数は年間平均47%減少しました。幸運なことに、2024年には Workforce Identity Cloud でSSRFバグは発見されておらず、対応も行われていません。
目指すべき状態
Okta Securityは、現在、同じカテゴリの他の脆弱性でもこの成功を繰り返すことを望んでいます。Okta製品セキュリティチームは、Bugcrowd VRTでサーバーセキュリティの誤った構成として分類されているすべての脆弱性への露出を減らすキャンペーンを開始する予定です。サーバーセキュリティの誤った構成のカテゴリは、70種類以上の脆弱性を指します。その多くは、発見やテストが難しい傾向があるため、厄介です。
現在は計画段階にあり、目標指標の設定、ダッシュボードの開発、次のようなさまざまなアクションが実行される予定です。
- 製品ユニット全体で脆弱性の分類を標準化
- Oktaの製品ポートフォリオ全体でこの脆弱性の追加の証拠を発見するための詳細なレビュー
- このクラスの脆弱性に焦点を当てるようにOktaのセキュアコーディングガイドラインを更新
- 特定のエンジニアリングチームを対象とした教育とセキュリティチャンピオンイニシアチブ
- スキャナーを使用して自動的に検出できる反復パターンの探索
- 推奨ライブラリまたは推奨される「デフォルトセキュア」な値の開発と推進
誓約の1年目の終わりに、結果の最新情報を提供します。
4. お客様のパッチ適用プロセスの改善
誓約書に署名してから 1 年以内に、お客様によるセキュリティパッチのインストールを大幅に増やすために実行されたアクションを実証します。
現状
Oktaは、必要に応じてお客様がクライアントソフトウェアの最新バージョンを簡単に維持できるように取り組んでいます。そのために、お客様が人間の介入なしにクライアントソフトウェアを自動的に更新できるように支援し、奨励しています。
Okta Workforce Identity Cloudのお客様は、オンプレミスのアイデンティティサービスと同期するActive Directoryエージェントと LDAPエージェントの更新の自動インストールを構成できます。Windows上のOkta Verifyクライアントも自動更新するよう構成できます。
多くのエンタープライズ組織では、本番環境に更新を適用する前にテストすることを好むため、自動アップデートはオプションのままです。当社はお客様にオプションを提供しています。
お客様がクライアントの自動更新を延期または無効にすることを選択した場合でも、Oktaは、お客様が実行しているクライアントのバージョンが新しい攻撃に対して脆弱であることが判明した場合にお客様に通知します。Oktaは、脆弱性情報をCVEとして脆弱性データベースに登録し、影響を受ける可能性のあるお客様を積極的に特定して連絡します。
管理者は、Admin Consoleの通知を通じて、特定のエージェントの最新バージョンが実行されているかどうかを確認できます。
Okta Verifyクライアントは、Oktaのデバイス管理パートナーのソリューションを使用して、Android、iOS、またはMacOS上で自動的に更新されるように設定できます。ユーザーは、AppleまたはGoogleのアプリストアからダウンロードしたOkta VerifyクライアントまたはAuth0 Guardianクライアントを自動更新できます。
目指すべき状態
Oktaは、サポート対象のプラットフォームで自動更新を提供することに注力しています。次の目標は、どのソフトウェアを更新する必要があるかに関する情報やコンテキストが不足しているために、お客様が取り残されることがないようにすることです。新しいタスクリスト項目や「受信トレイ」通知の作成など、管理コンソールで保留中の更新に関するリマインダーをより目立つ位置に表示する方法を検討しています。
5. 脆弱性開示ポリシーの公開
誓約書に署名してから1年以内に、脆弱性開示ポリシー (VDP) を公開します。このポリシーでは、製造元が提供する製品について一般の人がテストすることを許可し、VDP に従うために誠意を持って努力している人物に対して法的措置を推奨または追求しないことを約束し、脆弱性を報告するための明確なチャネルを提供し、調整された脆弱性開示のベストプラクティスと国際標準に沿って脆弱性を公開できるようにします。
現状
Oktaは、独立したセキュリティ研究者、お客様のレッドチーム、その他の関係者が当社のプラットフォームの脆弱性を発見し、責任を持って開示する機会を提供することに尽力しています。
Okta は長年にわたり脆弱性開示ポリシーを公開しており、2016年からバグバウンティプログラムを維持しています。現在、Oktaのバグバウンティプログラムには、Workforce Identity Cloud、Customer Identity Cloud、Okta Privileged Access、Okta Workflows、Okta Access Requests、Okta Device Access、Advanced Server Access、Okta Support Portal、クライアント ソフトウェア (Okta Verify クライアント、Okta ディレクトリエージェント、Okta ブラウザプラグイン) が含まれています。
Okta は、バグバウンティプログラムの開始以来、提出された400件を超える問題に対して金銭的な報奨金を提供し、440,000米ドルを超える報奨金を支払ってきました。
目指すべき状態
Oktaは、バグ報奨金プログラムですべてのOkta製品を100%カバーし続けることを目指しています。この目標を達成するために、Oktaは最近、Okta Access Gatewayと Okta Personalをプライベートバグ報奨金プログラムに追加し、Customer Identity Cloud (旧 Auth0)をプライベートプログラムからOktaのパブリックバグ報奨金プログラムに昇格しました。
Oktaは、今後もこれらのバグ報奨金プログラムに新しい製品を追加することに取り組んでいます。
6. 脆弱性の透明性の提供
誓約書に署名してから 1 年以内に、製造元の製品のすべてのCommon Vulnerabilities and Exposures (CVE) レコードに正確なCommon Weakness Enumeration (CWE) および Common Platform Enumeration (CPE) フィールドを含めることで、脆弱性報告の透明性を実証します。さらに、少なくとも、お客様によるパッチ適用が必要な、またはアクティブな悪用の証拠がある、すべての重大または影響度の高い脆弱性に対して、タイムリーにCVEを発行します。
現状
Oktaは、お客様と締結した契約条件に従って、Oktaソフトウェアおよびサービスで発見された脆弱性に対処します。
さらに、Oktaは、Oktaコンポーネントで発見された脆弱性がOktaのお客様側での対応を必要とする場合にCVEを公開しています。Oktaは、CISAおよびMITREによって脆弱性情報をCVE (Common Vulnerabilities and Exposures) 速報として公開することを認可されたCVE番号機関 (CNA)です。お客様がインストールしたOktaクライアントおよびエージェントのCVE速報は、次の場所で公開されています。trust.okta.com/security-advisories/.
目指すべき状態
Oktaは、以下の条件を満たす脆弱性についてもCVE速報を公開することを約束します。
- Oktaのお客様が、リスクを軽減するためにセキュリティアップデートを適用する必要がある。または
- セキュリティアップデートはないが、リスクに対処するために推奨される信頼性の高い回避策、緩和アクションがある。または
- 1つ以上のOktaのお客様でその脆弱性を積極的に悪用される可能性がある。
このアプローチは、Oktaのお客様がリスクにさらされていることを理解することに対する正当な利益と、お客様を不必要なリスクから保護すること、そして、軽減する権限のないリスクについてお客様チームが責任を負わされた場合に課せられる「チケット疲労」の負担を軽減することとのバランスをとります。
このアプローチでは、一部の脆弱性がパブリックドメインに公開されず、他の当事者がこれらのバグから教訓を得る機会が制限されることを認識しています。これを念頭に、Oktaは、Oktaサービスで対処された脆弱性について、このような開示方法がお客様にリスクをもたらさないように、透明性を高めることに取り組んでいます。たとえば、Oktaは最近、この透明性を実証する1つの方法として、Okta FastPassクライアントの悪用に関する調査の短い歴史を公開し、ラスベガスで開催されたOktane 2024でも同じテーマについて発表しました。
多くのお客様にとって、より重要なのは、適切なセキュリティ情報を適切な関係者にタイムリーに届けることです。Oktaは、セキュリティ関連情報をお客様に開示する方法の改善に取り組んでいます。Oktaのお客様で、CISO/CIOおよびセキュリティ担当の連絡先をOktaアカウント担当者に提供していない場合は、今すぐに提供してください。
7. お客様向けのログ記録と監視を改善
誓約書に署名してから 1 年以内に、メーカーの製品に影響を及ぼすサイバーセキュリティ侵入の証拠をお客様が収集する能力が目に見える形で向上したことを実証します。
現状
すべての Okta製品には、管理者がアクセスの問題をトラブルシューティングし、セキュリティチームが疑わしいアクティビティを監視するためのメカニズムが用意されています。
ログに記録されるイベントには、少なくとも、認証およびアプリケーションアクセス イベント、管理者およびユーザーのアクション、セッションコンテキスト、アクションのソースとターゲットに関する情報が含まれます。
ログに記録されるイベントは通常、Admin Consoleで、またAPIおよびログストリーミングを介してプログラムで利用できます (下の表を参照)。
Okta Workforce Identity Cloud |
Okta Customer Identity Cloud |
Okta Access Gateway |
Fine-Grained Authorization (新機能) |
|
出力するイベント |
Okta Identity Engine、Okta Privileged Access、Okta Identity Governance、Identity Threat Protection、Okta Device Access のすべてのユーザー、管理者、サポート イベント |
ユーザー認証と管理者イベント |
ユーザー認証、アクセス、承認、管理イベント。管理者は、ログに記録されるイベントの種類と詳細度を管理できます。 |
更新イベント |
ログファイル保持期間 |
90 日 |
サブスクリプションレベルに準じます。エンタープライズライセンスのお客様の場合は30日間 |
30 日 |
N/A |
管理者によるログへのアクセス |
イベントは、Okta Admin Consoleで直接参照、検索、フィルタリングできます。 |
イベントは Auth0 ダッシュボードで直接参照、検索、フィルタリングできます。 |
イベントはOkta Access GatewayのAdmin Consoleで閲覧、ダウンロードできます。 |
N/A |
プログラムによるログへのアクセス |
ログイベントはほぼリアルタイムでセキュリティツールにストリーミングでき、システムログAPIを使用してクエリやフィルタリングも可能 |
ログイベントはほぼリアルタイムでセキュリティツールにストリーミングでき、Auth0 Management APIを使用してプログラムでクエリおよびフィルタリングすることもできます。 |
管理者は、ログ フォワーダーを構成して、Okta Access Gateway ログをセキュリティ ツールにプッシュできます。 |
変更イベントは、Read Changes API を使用して照会できます。 |
Oktaは、セキュリティのユースケースにおいてログイベントをより有意義なものにすることを継続的に目指しています。
2024年8月だけでも:
- Okta は、Workforce Identity Cloudでセッションまたはトークンごとにイベントを関連付ける新しい方法を提供しました。新しいrootSessionIdフィールドがさまざまなユーザーイベントに追加され、セキュリティチームがユーザー セッションのコンテキスト内で実行されたすべてのアクションを関連付けるのに役立ちます。新しいrootTokenIdフィールドがさまざまな管理APIイベントに追加され、お客様のセキュリティチームが特定のトークンを使用するすべての API呼び出しを関連付けるのに役立ちます。
- Oktaは、Customer Identity Cloudの管理者に、セキュリティまたはリスクに関連するイベントタイプ (検出と対応に関連するものなど) のストリーミング パフォーマンスを他のイベントタイプよりも優先する機能を提供しました。
目指すべき状態
Oktaは、お客様のセキュリティチームが疑わしいイベントに効果的に対応するのに役立つさまざまな追加改善を特定しました。
Okta Workforce Identity Cloudのロードマップには、次の内容が含まれます。
- 現在ベータ版であるOkta AIを搭載したLog Investigator を一般提供にする予定です。Log Investigatorを使用すると、管理者は自然言語プロンプトを使用してシステムログクエリを作成できます。これにより、システムログイベントの操作に必要なドメイン知識のハードルを下げることができます。
- さまざまな構成イベントに新しいchangedDetailsフィールドを追加し、お客様のセキュリティチームが構成イベント後の以前の状態と現在の状態との差分をすばやく識別できるようにします。
- ワークフロー実行用のオプションのシステムログイベントを提供します。
Okta Customer Identity Cloudのロードマップには、次の内容が含まれます。
- Auth0セキュリティセンターで設定されたお客様定義のしきい値からの逸脱に対して、アラートと視覚的なインジケーターを提供します。
- 構成の変更、管理権限、および現在の有効なセッションに関するチーム固有の監査ダッシュボードを提供します。
- Auth0 Admin Console用の視覚的なセッション管理ダッシュボードと、セッションを取り消す機能を提供します。
Okta Fine-Grained Authorizationのロードマップには、次の内容が含まれます。
- 2025年前半に新しいFGA製品のログストリーミングを提供します。
おわりに
Oktaは、テクノロジーメーカーの間で セキュアバイデザインを推進するCISAの取り組みを称賛し、感謝しています。
当社は、お客様、パートナー、同業者、CISA と連携して、すべてのユーザーに対してより強力なデフォルトセキュリティ レベルを実現することにさらに貢献していきたいと考えています。