OIEは歩いてこないので、こちらから歩いて行ったという話
都合よくOkta Identity Engine（通称OIE）の本番環境テナントが手に入ったので、自社のテナントをClassic Engineから移行しました。
今回はその移行準備について記事にしました。
この記事は執筆含めて1日くらいなので、ほぼ日報です。
テナントの初期設定とユーザ登録・初回認証の流れは設計が完了したところです。アプリケーション移行とユーザへの説明はこれからです。
移行方式について
私の知る限りではOIE環境に移行する方法は２つあります。
１つは既存のClassic Engineをアップレートする方法。ただし、これは結構先になりそうですし、OIE環境でサポートされない機能を利用していると移行方式の調整などで影響を受けそうです。
もう１つは、新しくテナント（OIE環境）を取得して、既存環境から引っ越しする方法。こちらは力ずくですね。新規セキュリティポリシー、ユーザアカウント、および、ユーザへのMFA再設定。各アプリケーションの移行など前者と比べユーザ影響が大きいです。
ちなみに、今回は後者の移行方式を選択しています。
既存のClassic Engine環境はそのまま残すので、そのうちこっちもOIEにアップデートした際に記事にできるかと思います。
なぜ新規環境へ移行したか
なぜ、一見ユーザ影響が大きそうな後者の方式を選択したかですが、プロコンを定量的に比較してみるとどちらの方式も対して差はないんですね。
だったら、未知数のリスクがある方式よりも、見えている地雷であったとしても自分でコントロールしやすい新規環境への移行を選択しました。
アップデートを待っていられなかったということもあります。
また新規環境でやりたかったこともありました。主にこれらですね。
カスタムURLドメイン
ルール定着以前のポリシー（ごみ）
検証時の設定（ごみ）
NIST準拠のパスワードポリシー、またはパスワードが「ない」状態
新規環境で行ったこと
1.Custom Domain URLの登録
これは新規テナントじゃないとできないやつですね。Oktaテナントを{subdomain}.okta.comではなく、独自のドメイン名を付けるやつですね。
ブランディング用途で使われたりしますが、カスタムログインページを使歌めにも必要ですね。
興味ない人は読み飛ばしてください（笑）
新規テナントなので、元々利用していたサブドメインとは別の名付けが必要になります。イマイチな案しか出なかったので、カスタムドメインの利用を決めました。
2021年末の機能拡張で、OktaがSSL証明書を自動更新してくれるようになったので、それも追い風になりました。
ちなみに、3年前にChrome OSのログインをOkta認証にする検証をした際には、カスタムログインページの利用が必須だったりしましたね。
Primary colorの調整はあんまり薄い色にすると、埋め込み文字が黒字になってしまいました。白字にしたかったので、企業カラーよりちょっと濃いめの調整を入れました。
正直セキュリティポリシーや移行方式の検討よりも、ここに時間をかけちゃいましたね。
2.セキュリティ関連の設定
Security Notification Emails関連は大体Enableにしておきました。基本的にはAuthenticatorの登録とリセットくらいですが、OIE環境におけるNew Sign-onのタイミングのデータを取るのが目的ですね。
Classic EngineですとDevice Finger PrintとかDevice IDとかで判断されていました。OIEだとUniversal Directory上でDeviceが管理されるので、登録デバイスベースでの評価になるのではないかと思っています。
※未検証状態ですし想像で書いています。
Okta ThreatInsight Settingsは
Log and block authentication attempts from malicious IPsを設定します。
これにすることで正規ユーザが認証できなくなる可能性もあります。
OIE環境ではアクセス不可になりがちな原因のID入力・パスワード入力の機会が減らせるので、そうそうブロックされることもないかと。
念の為、自社のグローバルIPをホワイトリスト登録しておくなど、いざという時の逃げ道を準備しておくのもいいでしょう。
3.Authenticatorの設定
自社の新しい認証方式としては、Okta VerifyによるFastPassとFido2認証を中心に設計していきます。
そのあたりは他に詳しく書いてくれる方がたくさんいると思うので、さらっと。
FastPassのボタン表示は是非やりましょう。Okta Verifyのダウンロードリンクをユーザに案内しやすくなります。
User Verificationは普通に考えれば「Required」にすべきなのですが、全てのデバイスに適応できるポリシーではないのでデフォルトの「Preferred」にしています。
だがしかし、Fido2お前は「Required」だ。
Email認証とSMSなどは認証方式としては微妙なのでリカバリ手段だけとし、認証用のAuthenticatorからは除外しました。
認証は宗教なので、ここは自分の神に従ってください。
最後にパスワード。ここは小一時間ほど悩みました。
初回登録時の認証を既存テナントを使ったOrg2Org構成にすることで、新規テナントはパスワードなしの状態かつ、FastPass認証と構成を組むことは技術的に可能です。
ただし、新しいAuthenticatorの追加や認証付加時のリカバリ手段を考えていくと知識要素の撤廃はまだ時期尚早かなと判断しました。
パスワードポリシーは、聖典であるNIST SP800 63Bベースで作りました。
普段の企業様相手だとあまり提案できないような思い切ったポリシーにしておきましたよ。NG出されたらしれっと直します。
4.Sign-on Policyの設定
ここはOrg Sign-on Policy（OSOP）の設定ですね。Classicテナントでは個々の設定がキモでした。
OIE環境では打って変わってシンプルなものに変更しました。Application Sign-on Policy（ASOP）でポリシー管理するためですね。
とはいえ、まだASOPのシェア機能が実装されていないので設計は工夫が必要です。
各アプリごとにポリシー設定するのは遠慮したかったので、OSOPはネットワークによらず、ASOP準拠かつ2要素必須とするポリシーにしました。
※まあ、デフォルト値の関係でASOPは設定が必要なんですけどね。
5.Okta Dashboardアプリケーションの設定
パスワードレス認証にするために必要な設定です。
組み込みのDashboardアプリケーションを使って設計していきます。
私は「Any 2 factor types」を選択しました。
最初は「Possession factor 」でもいいかなと思っていたんですが、パスワードレス認証をすることが目的なのではなく、パスワードを用いないセキュアな認証をすることが目的ですので「Any 2 factor types」にしています。
昨今、巷では安易なパスワードレス認証の押し売りが横行しているそうなので、皆様もお気をつけください。
結果的に「Any 2 factor types」にしたとて、ユーザが認証時にPIN・生体認証を活用してくれれば、利便性が良くなるところが気に入りました。しない人は利便性が良くならないので苦しめばいい。
私はセキュリティは経営の課題だということを前提としつつ、ユーザのアイデンティティや認証強度はユーザ自身に意識してもらうべきという考えです。
この後の展開
パイロットユーザが問題なくアカウントの初回認証が可能なことは確認し、手順も確立できました。
この後は、アプリケーションの移行と、ユーザの皆様に土下座してユーザ移行をお願いするだけです。
色々と課題は出てきそうですが今月中には移行完了する見込みです。その際に出たものはこの記事に追記できたらいいなと思います。
この記事が気に入ったらサポートをしてみませんか？