- ナレッジセンター
- 匠コラム
Oktaレシピ ①統合ID管理
- 匠コラム
- クラウド
- セキュリティ
ビジネス開発本部 第1応用技術部
セキュリティチーム
渥美 淳一
はじめに
以前、Gartner が 4 年連続でアクセス管理のリーダー企業に選出した IDaaS の「Okta」をご紹介しました。
複数の IDaaS を検証してまいりましたが、結果、Okta はナンバーワンと称される強みを持っていることが分かりました。
今回は、その強みのひとつ『統合 ID 管理』を実現する Okta 機能についてご紹介します。
ゼロトラストを目指す組織にとって、「いつ？ 誰が？ 何をしたか？」を追跡できることが重要です。
まずは「誰が？」を特定できるように、Okta を中心にユーザーの ID およびアクセスを管理してみたいと思います。
なぜ Okta を中心に ID を管理するのか？
これまで、Active Directory や LDAP などを中心に組織内の IT 利活用のための ID 管理が行われてきました。
これにより管理者は「誰にどのリソースへのアクセスを許可するか」を管理しやすくなりました。
ユーザーも、一度ドメインにログインすれば適切なリソースへアクセス（シングルサインオン）できるようになりました。
ただしこの恩恵は、基本的にファイアウォールの内側、オンプレミスのリソースへのアクセスにおいて受けられるものです。
クラウドへのアプリケーションの移行に伴い、ID 管理のあり方も大きく変わります。
クラウドアプリケーション（SaaS）はそれぞれで ID 管理できます。
しかしユーザーは SaaS ごとに異なるパスワードを設定するのが億劫で、同じパスワードを使い回す恐れがあります。
組織としても利用する SaaS の数が増えるほど、SaaS ごとの ID 管理が大きな負担になります。
組織変更があると、変更後の所属部署に応じて SaaS を使えるようにしたり、逆に使えないようにしたりする必要があります。
退職者がいれば、その ID を削除または利用停止しなければ情報漏洩などのリスクが生じます。
この運用を人の手に任せるには限界があり、ミスも生じやすく、結果「DX」から遠ざかってしまいます。
そこで統合 ID 管理です。
Okta を使えば、複数の Active Directory や LDAP、クラウド人事サービスなどから ID を取り込み、まとめて管理できます。
なぜ、クラウド（IDaaS）なのでしょうか？
なぜ、Okta なのでしょうか？
その理由の一つは、Okta のセキュリティに対する包括的なアプローチです。
昔、私は「クラウドは危険」という先入観を持っていました。
しかし Okta に関しては、以下のホワイトペーパーを読んでイメージが変わりました。
Okta Security Technical Whitepaper | Okta
オンプレミスの ID 管理において、これ以上のセキュリティ対策が可能でしょうか？
不可能ではないかもしれませんが、相当な労力を費やすことでしょう。
オンプレミスの Active Directory もサイバー攻撃に狙われる世の中になりました。
ゼロトラスト、DX において、その礎となる ID 管理システムをスムーズに統合し、セキュリティ対策も実現。
さらに入社、異動、退職などで ID 情報に変更があったら自動的に SaaS へ反映する、ID ライフサイクル管理。
そしてユーザーには多要素認証などによる本人確認の徹底と、シングルサインオンによるエクスペリエンスの向上。
オンプレミスでこれらのシステムを構築、運用するプレッシャーから解放してくれる Okta に注目が集まります。
将来、必要となるアプリケーションとの連携や新しいビジネスも視野に入れやすくなるでしょう。
Okta で ID 管理する
Okta は以下のユーザーを管理できます。
|
Okta へのユーザーインポートに対応しているディレクトリやアプリケーションはこちらです。
Okta に手動で作成、または CSV ファイルからインポートされたユーザー
Okta の管理者コンソール（GUI）から直接ユーザーを作成できました。
そのとき、ユーザーのメールアドレスを Username として登録します。
会社のメールアドレスや Gmail アドレスを利用できました。
作成されると、ユーザー（メールアドレス）宛に Okta からメールが届きます。
ユーザーはそれに従うだけで Okta に多要素認証でログイン可能になります。
また CSV ファイルに書かれた複数ユーザーのインポートによってもユーザーを作成できました。
（CSV ファイルのテンプレートは Okta 管理コンソールからダウンロードできました）
Active Directory や LDAP などのディレクトリからインポートされたユーザー
Okta によって、従業員の ID 管理に既存のディレクトリを引き続き利用できます。
ユーザーはこれまでの資格情報（パスワード）を使ってさまざまな SaaS にアクセスできます。
これを実現するために、Okta Agent をインストールします。
Okta は複数の Active Directory や LDAP ドメイン環境をサポートします。
Active Directory や LDAP を統合するとき、ファイアウォールの変更は不要です。
（Agent から Okta への接続には 443 番ポートのアウトバウンド SSL を使用）
Agent は複数の Windows Server にインストールすることで冗長性を確保できます。
一台の Agent でも、接続が切れてしまった場合は管理者にメールで通知できます。
Salesforce などのアプリケーションからインポートされたユーザー
既に Salesforce などの SaaS で ID 管理されているケースもあります。
Okta へのユーザーインポートに対応している SaaS であれば、それも Okta に統合できます。
対応している Salesforce から Agent を使わずに Okta へ ID 同期できました。
そのユーザーを Okta が管理し、多要素認証します。
そして Salesforce や Microsoft 365 にシングルサインオンできました。
Salesforce は 2022 年 2 月 1 日より、アクセスに多要素認証を必須条件とすることを決定しました。
多要素認証（MFA）への対応のお願い | Salesforce
Okta のような SSO プロバイダーの多要素認証も、この条件を満たします。
Salesforce は多要素認証を追加費用なしで使えます。
しかし、他の SaaS も同様に、多要素認証を検討する良い機会と考えます。
多要素認証も Okta で統合し、利用する複数の SaaS を「多要素認証あり」にしましょう。
Okta でグループを管理する
次に、部署などのグループを Okta に作成します。
そして所属するユーザーをそのグループに入れます。
Active Directory が管理する「Domain Users」などのグループを Okta へ同期して活用することもできます。
ユーザー属性に特定の値が含まれるユーザーを、自動的にグループに追加・削除することもできます。
最後にグループに対して、アクセスを許可するアプリケーションを割り当てます。
例えば「Sales」グループのユーザーには Salesforce へのアクセスを許可する、というルールを定義できます。
また、グループによって異なる多要素認証ソリューションを採用できます。
パスワードの文字数などのルールを決める「パスワードポリシー」もグループごとに設定できます。
ユーザーは複数のグループに所属できます。
おわりに
今回は既存のディレクトリを継続利用し、さらにクラウドへと拡張するイメージをご紹介しました。
今後も Okta を中心に、お客様にとって有益なレポートを積極的に公開してまいります。
ご興味がおありでしたら是非、お気軽に弊社の担当営業までご連絡ください。
Webからのお問い合わせはこちらから
ピックアップ
ナレッジセンターを検索する
カテゴリーで検索
タグで検索