AMaaS ＞IDaaS：クラウドとオンプレの ID を統合

Pushing the Limits of IDaaS with AMaaS

2021/07/29 SecurityBoulevard — データへの安全なアクセスは、誰にとっても大きな懸念となる。そこで、クラウド ID 管理ソリューションとして、IDaaS (identity-as-a-service) が随所で採用され、アプリケーションにアクセスするユーザーが、本人であることの確認が、つまり、ID の認証が行われている。しかし、IDaaS は、問題の半分しか解決できない。個人情報保護法では、個人を特定できる情報 (PII) などの機密データに、適切な人だけが適切なタイミングでアクセスするよう求められている。

そのためには、認証された各ユーザーの、セルレベルにまで至る情報へのアクセス権を、包括的かつ最新の方法で管理する必要がある (例：SSN の下４桁へのアクセスとSSN 全体へのアクセス)。また、現在の IDaaS ソリューションでは、アプリケーション統合における多大なエンジニアリング・リソースの要求という、開発チームに対する大きな負荷を生じており、価値を生み出すまでの時間を遅らせている。

さらに、今日のハイブリッド・マルチクラウド環境では、複数の認証シナリオに依存する可能性があり、IT チームとガバナンス・チームに混乱を招き、エンド・ユーザーの使い勝手を悪してしまう。その点、AMaaS (Access Management-as-a-Service) は、ハイブリッド・マルチクラウド・インフラ全体のアセット (アプリケーションや API など）に対して、分散型の認証と認可を追加し、それらのアクセス・ポリシーを集中管理するための、新しい戦略として注目されている。

IDaaS の限界

権限付与：IDaaS ソリューションの一部は、限定的な認証機能を提供しているが、GDPR (EU General Data Protection Regulation) や CCPA (California Consumer Privacy Act) などの、新たなデータ・プライバシー規制への準拠を保証するだけの、十分なきめ細かさ (URL レベルなど) を備えていない。

統合作業：アプリケーションおよび API を、IDaaS ソリューションと統合する開発チームは、OAuth / OIDC / SAML などの最新の認証／認可プロトコルや、各種プラットフォームの SDK や API を習得する必要がある。また、開発者は、IDaaS ソリューションと統合するアプリごとに、統合コードを書く必要がある。数百から数千のアプリケーションを保有する企業では、たとえ開発チームが十分なトレーニングを受けていたとしても、時間とコストのかかる作業を強いられる。

最新の IDaaS にレガシー・アプリケーションを移行するときには、コードの大幅な書き換えや、エラーを起こしやすい手動による設定ステップが必要になる。セキュリティ専門家による指導のない状況で、これらの作業を進めてしまうと、IDaaS への移行により向上するセキュリティ・レベルを、台無しにしかねない脆弱性を取り込んでしまう可能性が生じる。

最終的に、IDaaS ソリューションが導入されたても、アクセス管理ソリューションを追加するには、さらに多くの作業が必要とある。従来のオンプレミスのゲートウェイ・ソリューション (Web アクセス・マネージャーなど) は、高価でインストールが難しく、アプリを搭載するのも困難だ。また、これらのレガシー・ゲートウェイ・ソリューションのローカル・コントロール・プレーンの設計は、管理を困難にしている。また、カスタムの認証システムを、最新のプロトコルで書き換えることも、時間とコストを消費する。

ハイブリッド・マルチクラウド：オンプレミスとパブリック・クラウドで稼働するアプリケーションの場合には、それぞれが異なる IAM (identity access management) ソリューションを採用していることが多い。このため、分散アーキテクチャ全体で、IAM ポリシーを一貫して実施することは極めて困難であり、セキュリティ・ギャップやプライバシー規制の違反につながりやすい。

AMaaS と一元化された認証戦略

AMaaS の目的は、クラウドで提供され、クラウドで管理される、アクセス管理ソリューションを提供することにある。このソリューションは、IDasS ソリューションとシームレスに統合され、アプリケーションや API に対する SSO (single sign-on) や MFA (multi-factor authentication) を可能にし、ハイブリッド・マルチクラウド・インフラストラクチャ全体で、きめ細かな条件付きアクセスを実施する。通常、AMaaS ソリューションでは、Gartner の言うサイバーセキュリティ・メッシュ・アーキテクチャが採用され、以下の２つの主要コンポーネントを含む。

・分散型ポリシー実施ポイント (PEP: policy enforcement points)：インフラ全体の資産（アプリケーションやAPIなど）の近くに配置されたゲートウェイやエージェントの形式で、特定の資産セットに対して認証／認可を実施するために使用される。

・集中管理コンソール (CMC: centralized management console)：通常はクラウド内に置かれ、アセットと共に配布されたPEPを管理する。このコンソールでは、設定やアクセス・ポリシーの管理、アクセス・ログの収集、レポート／ダッシュボードの生成が可能となる。高度なプラットフォームの中には、AI を利用した脅威の検知／防止の機能を提供できるものもある。

AMaaS ソリューションの基礎となる原則は以下の通り

・OAuth / OIDC / SAMLなどの最新セキュリティ・プロトコルのサポート：これらのプロトコルは、今日の SSO の標準となっており、さまざまなアプリケーションにログインするユーザーに、よりシンプルで便利な体験を提供する。また、セキュリティも向上する。

・グループ / ロール / IP / ブラウザなどの、ユーザーやデバイスの詳細な属性に基づくアクセス・ポリシー定義：企業による権限管理の一元化は、増え続ける複雑なシナリオに対応したポリシー管理を必要とする。たとえば、PII を含む顧客データベースへのアクセスは、従業員の役割やグループおよび、その時点の居住地により制限される場合がある (たとえば、特定の国で働いている間は、一部の PII へのアクセスが許可されるが、国外に出た場合には許可されないなど)。

・ハイブリッド・マルチクラウド環境のサポート：アプリケーションやデータセットがオンプレミスに存在しても、あるいは、パブリック／プライベート・クラウドに存在しても、それは問題にならない。分散されたエージェントやゲートウェイは、どこのアセットが存在しているかに関わらず、それらのアセットと共にデプロイされるべきだ。また、エージェントやゲートウェイは、通常はクラウド上の集中コンソールで管理される。

・最小限のコーディング：コーディングやセキュリティに関する専門知識を、可能な限り必要としないソリューションであること。それは、移行の迅速化／コストの管理／セキュリティの確保のために必要となる。

AMaaS の運用

AMaaS ソリューションは、２つの一般的な課題を克服するのに有益である。まず、例として、I T リソースが限られている中堅企業で、オンプレミスのレガシーアプリケーションとクラウドベースの SaaS を混在させて利用するケースを考える。SaaS アプリケーション (例：Workday / ServiceNow) は、最新のプロトコル (例：OIDC) をサポートしているため、IDaaS ソリューション (例：Azure AD) を SaaS アプリケーションと簡単に統合できまる。

しかし従業員は、レガシー・アプリケーションに対して、IDaaS のシンプルで使いやすい SSO や MFA を活用することができず、レガシーの ID システムを介してログインしなければならない。AMaaS ソリューションを利用すれば、レガシー・アプリケーションを最新の IDaaS プラットフォームへと、簡単に移行することが可能となり、従業員は真の SSO シナリオを実現できる。

別の例は、Fortune 500 にランクインしている金融機関であり、いまだにほとんどのアプリケーションをオンプレミスで運用しているケースとなる。最新の IDaaS プラットフォームの導入を開始しているが、ユーザーの ID や属性を保存するために、いくつかのレガシー・システム (例：オンプレミスの AD や LDAP ストア) を使用している。

AMaaS は、これらの異なる ID システム (最新の IDaaS またはレガシー) を接続し、異なるシステムに散在する異なるユーザー属性を組み合わせて、統合的なアクセス制御を可能にし、複雑な分散ハイブリッド環境のアプリケーションに対して、集中管理されたアクセス・ポリシーを実施できる。そのために必要とされるのは、最小限のコードの調整であり、数ヶ月の開発時間を節約でき、IT チームやセキュリティ・チームは他の課題に集中できる。

今日のエンタープライズ・インフラの特徴を要約すると、刻々と変化する様々なソリューションで埋め尽くされていることになる。ある企業では、ハイブリッド・マルチクラウド環境で、IDaaS ソリューション (Microsoft Azure AD / Okta / Auth0 など) を混在して使用することもあるだろう。したがって、それぞれの組織がセキュリティとユーザー・エクスペリエンスの目標を達成するための、最も幅広いソリューションをサポートすることが、AMaaS の本質となる。

この種の話となると、まず思い浮かぶのが、Microsoft の Active Directory であり、Azure Active Directory であり、となります。クラウドが登場して定着したことで、新しい ID 管理の指針が定まってきたのでしょう。それは、セキュリティの実現方式と、表裏一体のものだと思えます。Microsoft のサイトには「Azure AD では IDaaS ソリューションを組織に提供することで」と明記されているので、まだまだ先の長い話なのでしょう。よろしければ、「覚醒必須：API の脆弱性を先回りして特定する」と「API ファースト時代のアプリケーション保護を再考する」を、ご参照ください。