オンプレミスとクラウドの ID を効果的にブリッジするには

How to Bridge On-Premises and Cloud Identity

2021/07/15 DarkReading — 組織が管理すべき ID の数は膨大であり、気が遠くなるほどだ。場合によっては、何十万/何百万もの人々/デバイスが存在することもある。歴史的にみるとは、これらの ID は、ビジネスアプリケーションや、レガシーの ID インフラストラクチャ、そして特定のデータセンターにハードコードされた、いくつかの内部 ID サイロに分散していた。

今日、ID サイロは、企業が利用するクラウド・サービスや SaaS (Software-as-a-Service) アプリケーションにも出現しており、膨大かつ分散したインフラストラクチャを管理する上での課題となっている。さらに悪いことに、企業が新しいクラウドを立ち上げるときや、新しいデバイスを導入するときに、その数と複雑さは増加の一途をたどっている。このような状況を打開するためには、より包括的で合理的なアプローチをとることが重要だ。

アクセスとコントロールが統一され、企業の環境全体が可視化されるなら、バラバラで断絶された ID サイロは出現せず、より効果的なガバナンスとセキュリティが実現する。そこで登場するのが、次世代の IAM (Identity Access Management) と言われる ID ファブリックになる。ID サイロを接続し、タスクを統一することで、企業はコストを削減し、ID の管理に費やすスタッフの時間を削減し、セキュリティとコンプライアンスを向上させることが可能となる。

ファブリックの拡張

多くの企業は、今日の複雑で異質なマルチクラウド IT 環境の中で、ルールやポリシーを適用することに苦労している。ID ファブリックは、この問題を解決するために、個々のクラウド・プラットフォーム/ID プロバイダー/SaaS アプリケーション/データ・サービス/ネットワークの統合を、多層化されたスタックを超えて実現する。このスタックには、AWS や Azure などのクラウドサービス/SaaS アプリケーション/データシステム/Software-Defined Network プロバイダなどが含まれる。[注:筆者の会社は、ID ファブリックを提供する数多くの企業の1つである]

接続性が確立されると、ID ファブリックは、異種環境のオーケストレーションを可能にし、一貫したアイデンティティおよびアクセス・ポリシーの管理を実現する。集中的に定義されたアクセス・ポリシーは、ターゲット・システムがサポートする実際の言語および構造である、ネイティブ・ランタイム形式でターゲット・システムに配布される。このフレームワークを駆動するエンジンは、統合と展開を容易にするために API ベースとなっている。既存の API を利用することで、カスタム・コーディングの必要性を減らし、場合によっては完全に排除することも可能だ。

これにより、企業はシステムを迅速かつ効率的に接続し、実際の ID 管理や認証に必要な、すべてのポリシー変換も可能となる。たとえば、特定のアプリケーションが多要素認証 (MFA) を必要とする場合には、ファブリックから適切な ID/MFA プロバイダーにはプロセスがルーティングされ、そこでアクションが実行される。企業がマルチクラウド環境や多様な SaaS アプリケーション(それぞれが異なる標準やフレームワークを持つ)に移行していく中で、ID ファブリックが機能することで、ID を手動で管理/接続する必要性が排除される。その結果として、ID ファブリックは、より合理的で柔軟なアプローチを可能にする。

素材の利点

ID ファブリックには、別の利点もある。たとえば、データセンターからクラウドへの移行や、あるクラウドから別のクラウドへの移行などを簡素化できる。また、企業の ID システムをオンプレミスからクラウドへと移行したい場合であっても、アプリケーションを書き換えることなくプロセスを推進できる。具体的に言うと、ID ファブリックが、すべての情報をマッピングして転送することになる。さらに言うなら、アクセス管理が中断されないため、セキュリティ・リスクが生じることもない。

ID ファブリックは、特定のビジネス・アプリケーションに適した ID システムへとユーザーを導く。例えば、Microsoft Azure AD へ移行する場合、移行の 1日目には、ユーザーはオンプレミスの既存のレガシー・アクセス管理システムで認証を行う。そして、移行プロセスが完了した2日目には、ユーザーはファブリックを経由して、Microsoft Azure Active Directory のクラウド ID システムに入る。ID ファブリックを導入する前に、考慮すべきいくつかの点がある。ID ファブリックを導入するには、すべてを接続するための、何らかのセントラル・サーバが必要となる。また、強固なディスカバリー・プロセスが必要であり、さらに、組織としては、ロール/アクセス権/認証方法などを扱う、明確なポリシーを確立する必要がある。

完全なオーケストレーションは、よく考えられたガバナンスとポリシーのフレームワークがあって、初めて可能になる。ID 管理は、IF ファブリックの方向へと向かっている。このクラウド・ネイティブなフレームワークは、複数の サイロ化した独自の ID システムの必要性を排除する。また、IAM の手動による操作という側面や、それに伴うセキュリティやコンプライアンスの課題も取り除く。それに代えて、組織は複雑な環境下でも、より迅速かつ効率的に業務を遂行することに集中できる。

CSIRT を担っている方々と話すと、この ID 管理に、皆さん悩んでいるようです。ただでさえ、レガシーを引きずる Active Directory に悩まされ、そこに各種のクラウド・サービスが追加され、さらに悩みは深まるばかりです。この記事に書かれているように、一連の ID の統合が進むと、かなりスッキリするはずです。ちなみに、この記事は Strata Identity の Head of Standards である Gerry Gebel さんが書いているようです。ご興味のある方は、上記のリンクをクリックしてみてください。

この記事は、IDそのものを管理する狭義の「ID管理」とIDを使う人を確認する「認証」のことが、ぼんやりとまとめて書かれているので注意が必要です。
認証を管理するためにはSAMLに代表される認証連携技術を使うことで、一元化を図ることができます。
一方それぞれのサービスに「アカウント」を作ったり削除したりするためには、「IDプロビジョニング」が必要です。このプロビジョニングを実現するのが狭義のID管理ですねー。
以上の説明で頭が混乱した人は、この記事に惑わさるかもかも???

%d bloggers like this: