【書評】 マスタリングOkta ―IDaaS設計と運用

はじめに

『マスタリングOkta ―IDaaS設計と運用』（オライリー・ジャパン）を読みました。原書は Okta Administration: Up and Running（Packt Publishing）で、日本語版は2021年12月に刊行されています。

「認証基盤は自分で作るもの」と思われがちですが、実際には IDaaS に任せたほうが設計も運用もシンプルになる領域 が多くあります。本書は、その代表格であるOktaを管理者の視点から体系的に解説した一冊です。

この記事では、設計・アーキテクチャに関心のあるエンジニア向けに、本書の要点と読みどころを整理します。

本記事は書評であり、本書の内容を筆者の理解でまとめ直したものです。詳細な手順や画面は、書籍および公式ドキュメントをご確認ください。

本書の概要

項目	内容
書名	マスタリングOkta ―IDaaS設計と運用
著者	Lovisa Stenbäcken Stjernlöf、HenkJan de Vries
訳者	髙橋 基信
出版社	オライリー・ジャパン
対象読者	Okta初心者、IAM領域を調査しているエンジニア
前提知識	特になし（無償の開発者版で試すことを推奨）

構成は全9章・2部立てです。

• 第1部 Okta入門（1〜6章）：UD、SSO、AMFA、LCM、UIカスタマイズ
• 第2部 Oktaの高度な機能（7〜9章）：API管理、ASA、OAG

基本機能から応用領域へと段階的に進むため、頭から順に読むと理解しやすい構成です。

全体像：Oktaの製品を一枚で捉える

本書を読み進める上で、まず製品の位置づけを頭に入れておくと混乱しません。

UDが土台にあり、その上に認証・認可・自動化の機能が積み上がっていく構造です。この「UDを中心に据える」という発想が、本書全体を貫くアーキテクチャ上の軸だと感じました。

各章の要点

1章：IAMとOkta

最初に、IAMの役割とOktaの立ち位置が整理されます。境界型セキュリティが成り立たなくなった背景から、ゼロトラストへの移行が必然であることが語られます。

印象的だったのは、ゼロトラストの成熟度を4段階で示している点です。

1. ステージ0：ディレクトリとアプリが散在している状態
2. ステージ1：SSOとMFAで統合IAMを実現した状態
3. ステージ2：コンテキストに基づくアクセス制御を行う状態
4. ステージ3：リスクに応じて動的に制御する適応型の状態

自社がどこにいるのかを客観視でき、導入計画のロードマップを考える材料になります。

2章：UD（Universal Directory）の活用

Oktaの根幹であるUDの章です。個人的には、この章が 設計の勘所 を最も多く含んでいると感じました。

ディレクトリ連携

• ADやLDAPとは、軽量なエージェント経由で連携します。
• 認証の委任により、ユーザーが管理するパスワードを増やさずに移行できます。
• Desktop SSOやパスワード同期は、それぞれ別のコンポーネントとして用意されています。

ユーザーの3分類

• Oktaがマスタのユーザー
• ディレクトリがマスタのユーザー
• アプリケーションがマスタのユーザー

さらに、ユーザー単位だけでなく 属性単位でマスタを切り替えられる 点が重要です。たとえば氏名はHR、電話番号はAD、といった使い分けができます。データの正（source of truth）をどこに置くかは、ID管理で最初に決めるべき設計判断です。

グループ設計

• グループにはOkta・ディレクトリ・アプリケーションの3種類があります。
• Oktaのグループには階層構造がありません。そのため、名称の先頭に数字を振って擬似的に階層化する工夫が紹介されています。
• 既存ADへの依存度が高い場合は、あえてOkta側にグループを作り直さない、という判断も示されています。

「Oktaに寄せるか、既存資産を活かすか」というトレードオフに正面から触れている点が、実務的で好印象でした。

3章：SSOによるユーザー利便性向上

SSOの章では、アプリケーションとの連携方式が整理されます。

方式	特徴	向いているケース
SWA	資格情報をOktaが代行入力する	フェデレーション非対応のアプリ
SAML	XMLベース、IdPとSPが署名付きで連携	企業向けSaaSの標準
OIDC	OAuth 2.0上の認証レイヤー	モダンなWeb・ネイティブアプリ

本書は、可能な限りSAMLやOIDCなどのフェデレーションを使うことを推奨しています。SWAはあくまで「それ以外に手段がない場合」の選択肢という位置づけです。

また、次の仕組みも解説されています。

• OIN：6,500以上のアプリとの連携カタログ
• パスワードポリシーとサインオンポリシーの使い分け
• 外部IdP連携とIdPディスカバリ（ルーティングルール）

ポリシーは上から順に評価され、最初に合致したものが適用されます。「範囲の狭いルールを上に置く」という鉄則は、ファイアウォールのルール設計にも通じる考え方です。

4章：AMFAによるセキュリティ向上

認証要素を、知識・所持・生体の3種類に分けて整理した章です。

• 知識要素：パスワード、セキュリティ質問
• 所持要素：Okta Verify、SMS、メール、FIDO2対応キーなど
• 生体要素：Windows HelloやTouch IDなど

本書の立場は明快で、SMSやメールは手軽だが強度は高くない と明記されています。導入しやすさと安全性のバランスを、現実的に評価している点が参考になります。

AMFA（Adaptive MFA）では、次のコンテキストを判断材料にできます。

• ネットワークゾーン（IP、地域）
• 振る舞い検知（新しい場所・デバイス・IP、不自然な移動速度）
• デバイス信頼（MDM連携）

「いつもと違う」ことを検知してMFAを要求する、いわゆるリスクベース認証の考え方が、具体的な設定項目と結びつけて説明されています。

5章：LCMによる処理の自動化

入社から退職までのアカウントライフサイクルを自動化する章です。設計という観点では、最も読み応えのある章 でした。

プロビジョニングの基盤

• SCIMによるユーザー情報の連携
• 作成・更新・無効化・パスワード同期の各動作を個別に制御

HRシステムをマスタにする

• Workdayなど、OINに連携が用意されているHRシステムをマスタにできます。
• 連携がなくても、APIやCSV（オンプレミス用エージェント経由）で代替できます。

式言語（Okta Expression Language）

• Spring Expression Languageがベースです。
• 属性マッピングの際に、文字列の加工や属性の組み合わせができます。

グループルール

• 属性値に応じてグループへ自動で割り当てます。
• 部署異動があると、旧グループから外れ、新グループへ入ります。

グループルールには注意点もあります。ルールに適用順がないこと、ルールが連鎖すると性能面の懸念があることが指摘されており、便利な反面、誤設定の影響が大きい と釘を刺しています。

ワークフロー機能

機能	呼び出し方式	用途の例
インラインフック	同期	SAMLアサーションやトークンの加工
イベントフック	非同期	Slackなどへの通知
オートメーション	条件ベース	一定期間未使用のユーザーを無効化
Okta Workflows	GUIのコードレス	複雑な入退社フロー

この整理は、システム間連携で「同期か非同期か」を考えるときの設計感覚と重なります。

6章：ユーザーインターフェースのカスタマイズ

利便性を高めるための章です。ダッシュボード、ロゴ、サインインページ、通知メールのカスタマイズが扱われます。

• カスタムURLドメインを設定すると、サインインページをHTMLで編集できます。
• 自前のページにサインインウィジェットを埋め込む場合は、CORSの設定が必要です。
• 全ユーザーへのダッシュボード設定は、個人の設定を上書きしてしまう点に注意が必要です。

どれほど強固な認証でも、使いにくければ現場で敬遠されます。セキュリティと使い勝手を両立させる という姿勢が、章全体から伝わってきます。

7章：API管理

第2部の最初の章です。OktaのAPIを使った管理の自動化と、API Access Managementが扱われます。

本書はAPIセキュリティを5段階で整理しています。

1. セキュリティなし
2. APIキー
3. OAuth 2.0
4. APIゲートウェイ
5. APIゲートウェイ＋API Access Management

特にレベル2の解説が鋭く、APIキーは複数サービスで使い回すほど権限が肥大化し、ローテーションが困難になる と指摘しています。この指摘は、自社サービスの認可設計を振り返る良いきっかけになります。

設定面では、次の用語を押さえておく必要があります。

• 認可サーバ：トークンの発行元
• スコープ：実行できる操作の範囲
• クレーム：トークンに載せる情報
• アクセスポリシー：どのクライアントにどのスコープを許可するか

署名鍵のローテーションは、Oktaが年に4回自動で実施します。クライアント側が鍵の更新に追従できる設計になっているかは、導入前に確認しておくべき点です。

8章：Advanced Server Accessによるサーバ管理

ASAは、ID管理の対象を サーバ にまで広げる製品です。

従来のSSH公開鍵認証には、次の課題があります。

• 鍵は静的で、ローカルに保管される
• 鍵が「誰か」を表さない
• コンテキストを考慮できない
• サーバの増減に追従したプロビジョニングができない

ASAは、利用時に短時間だけ有効な証明書を払い出す ことでこれを解決します。長期間有効な鍵がサーバに存在しなくなるため、鍵の漏洩リスクを根本から減らせます。

運用上の特徴は次のとおりです。

• 管理対象のサーバには、軽量なエージェントを導入します。
• 権限はプロジェクト単位で管理し、グループごとに付与します。
• Terraformなどと組み合わせて、サーバ登録を自動化できます。

「特権アカウントの共有をやめ、必要なときだけ最小権限を渡す」という考え方は、インフラ運用に携わる方なら共感できるはずです。

9章：オンプレミスアプリとOkta Access Gateway

最終章は、レガシーなオンプレミスアプリをOktaに統合するOAGです。

• ヘッダベース認証やKerberos認証を使う古いアプリでも、SSOやMFAの恩恵を受けられます。
• 従来のWAM（Web Access Management）製品の置き換えを狙った製品です。
• VM形式で提供され、管理ノードとワーカーノードによる冗長構成を取れます。

オンプレミスで動かすぶん、他のOkta製品より運用の考慮点が増える点は、率直に書かれています。「クラウド移行は一足飛びにはいかない」という現実を踏まえた章です。

本書を読んで得られた設計上の学び

通読して、特に設計の観点で持ち帰ったポイントは次の5つです。

1. データの正をどこに置くかを最初に決める
   • 属性単位でマスタを切り替えられるため、組織の実態に合わせた設計が可能です。
2. ポリシーは「狭い条件を上に」並べる
   • サインオンポリシー、MFA、アクセスポリシーのいずれでも共通の原則です。
3. 手軽さと強度はトレードオフ
   • SMSやメールは導入しやすい反面、強度は劣ります。要件に応じて組み合わせます。
4. 自動化は便利だが、誤設定の影響も自動で広がる
   • グループルールやプッシュ同期は、削除や名称変更の副作用まで確認が必要です。
5. 長期間有効な秘密情報を持たない
   • APIキーやSSH鍵を、短命なトークンや証明書に置き換える方向性が一貫しています。

良かった点

• 管理コンソールの操作手順が具体的です。手元の試用環境で追試しやすく、理解が定着します。
• 日本語版には、訳注が豊富です。原書の誤りやUIの変更点が補足されており、信頼性が高まっています。
• 日本語でまとまったOktaの情報源が少ないなか、体系的に学べる貴重な一冊です。
• 設定の羅列に終わらず、なぜその設定が必要かという背景にも触れています。

気になった点

• 出版から時間が経っているため、UIや機能名が現在と異なる箇所があります。たとえばプロファイルマスタの呼称などです。最新の仕様は公式ドキュメントで確認が必要です。
• Workflowsなど一部の機能は、訳者も検証環境を用意できておらず、画面が原書のままです。
• 有償ライセンスが必要な機能が多く、無償の開発者版だけでは試せない範囲があります。
• 実装コードを掘り下げる本ではなく、管理者向けの設定解説が中心です。アプリケーション開発者が深く知りたい場合は、OAuthやOIDCの別資料を併読すると良いでしょう。

こんな人におすすめです

おすすめ度	読者像
◎	Oktaの導入・運用を担当する、またはこれから担当するエンジニア
◎	認証基盤の設計を任され、IDaaSを比較検討している方
○	ゼロトラストの考え方を、具体的な製品に落として理解したい方
○	自社サービスにSSOや外部IdP連携を組み込みたい開発者
△	OAuthやOIDCの仕様を深く学びたい方（別の専門書が適切です）

おわりに

『マスタリングOkta』は、Oktaの機能を網羅しつつ、ID管理の設計思想 を学べる一冊でした。

特に印象に残ったのは、機能の説明の根底に「利便性と安全性は両立させるもの」という一貫した姿勢があることです。SSOもMFAも、そしてASAの短命な証明書も、すべては「ユーザーに負担をかけずに安全を高める」ための仕組みとして語られています。

認証基盤を自前で作り込む前に、IDaaSという選択肢を設計の俎上に載せたい方は、手に取ってみてはいかがでしょうか。

参考

• マスタリングOkta ―IDaaS設計と運用（オライリー・ジャパン）
• Okta Developer
• Okta Expression Language