次に当てはまる方を想定しています。
private_key_jwt への認証方式の乗り換えです。Okta 側の思想変更に CrowdStrike が追従した形になっています。この記事の立ち位置：CrowdStrike のドキュメントを翻訳して並べ直すことはしません。ここでは「なぜ必要か」「何が必要か」「実際に切り替えるときに気をつけること」に寄せています。
コネクタの基本的な仕様は次のとおりです。
okta-ssoprivate_key_jwt の組み合わせokta.logs.read取り込めるイベントは 4 系統あります。
取れる情報の中身は SSWS 版と変わりません。但しこのコネクタは取り込み専用です。OAuth2 版に変えたことで、認証要素のリセット、パスワードの強制リセット、セッションのクリアといった対応アクションが打てなくなります。機能継続には、Integration Content Library の Okta SOAR Action アプリが別に必要になります。
Okta (SSWS)
Tech Alert | 90 Day Notice | Okta Data Connector migration to OAuth2 authentication
Okta SOAR Actions
Okta社自身が静的 API トークンから OAuth 2.0 へ移るよう公式ブログで明言しています。理由は説明するまでもないですが、無期限に、誰が叩いているか分からない、強い権限をハードコードするなというメッセージかと思います。
Why you should migrate to OAuth 2.0 from static API tokens | Okta
Create an API token
セキュリティ論以前に、運用で刺さるのはこちらです。SSWS トークンは作成した管理者アカウントの権限をそのまま引き継ぎ、その管理者が無効化されるとトークンも道連れで消えます。退職した情シス担当が作った SSWS でログ連携していると、退職処理の翌日に SIEM へのログ流入が止まります。加えて 30 日間未使用で失効します。この 30 日という値は組織側で変更できません。
private_key_jwt は、秘密鍵をクライアント側に置いたまま、都度署名した JWT を使ってアクセストークンを取りにいく方式です。ネットワークを流れるのは短命なアクセストークンだけで、鍵そのものは飛びません。
SSWSベースのコネクタのサポートは、2026年12月7日までです。期限を過ぎるとデータ受信やサポートを受けられなくなります。
CrowdStrike側でFalconコンソールへの管理者アクセス権またはコネクターマネージャーアクセス権、Okta側でSuper Admin 権限を持つアカウントが必要です。
また、既存の SSWS トークンの持ち主を確認しておきます。現在のOktaコネクタを支えているトークンを誰の管理者アカウントで作成したのか。知見者はまだいるのかを念のため確認します。
公式の手順は 9 ステップありますが、実務では 3 つの塊で考えたほうが段取りしやすいと思います。
token_endpoint_auth_method が private_key_jwt になります。保存を押さずに次へ進みます。private_key.pem として保存します。一度しか表示されません。okta.logs.read を Grant します。
Connectors > Data connectors > Data connections で + Add connection を選び、「Okta Data Connector (OAuth2)」を検索します。
Data source configurationに各種設定を入力します。パーサーは okta-sso が既定で選ばれ、ホスト名エンリッチメントも既定でオンになります。
Status が Active になり、Last ingested が更新されていること、エラーメッセージが上がっていないこと、Advanced event search でイベントが見えることを確認してから、旧 SSWS 接続を削除します。
作業は以上です。
本記事はus-2リージョンを前提に記載されており、AIを用いて執筆しています。AIで言いたいことを3倍に膨らませる社風は無いためなるべくシンプルな構文に努めていますが、不足している説明や不明点があればお手持ちのAIブラウザから参照元のガイドにアクセスして更問いしてみてください。