アクセス管理 FAQ

IDおよびアクセス管理（IAM）はデータセキュリティの重要な要素であり、IDガバナンス管理（IGA）とアクセス管理（AM）の2つの機能を組み合わせています。

IAMは、アプリケーションへのアクセスを許可（および要求）（IGA）し、アクセス制御を実施（AM）し、アクセスイベントの可視性を確保（AM）するための体系的なフレームワークを提供します。

IGAソリューションは、「誰がどのアプリケーションにアクセスできるべきか、または誰がどのアプリケーションへのアクセス権を持つのか」や、「実際には、誰が、誰によって、いつ、どのアプリケーションへのアクセスを許可されたのか」という質問に答えるのに役立ちます。AMソリューションは、「誰がいつ、何にアクセスし、どのように彼らのIDが検証されたのか」という質問に答えるのに役立ちます。

IDおよびアクセス管理（IAM）ソリューションは、IDガバナンスと管理（IGA）機能とアクセス管理（AM）機能で構成されています。IAMソリューションは、アプリケーションへのアクセスを許可（および要求）（IGA）し、アクセス制御を実施（AM）し、アクセスイベントの可視性を確保（AM）するための体系的なフレームワークを提供します。ほとんどの企業がIGAコンポーネントとAMコンポーネントを別々に展開していることを考えると、これらの機能は、単一のIAMスイートの複合機能としてではなく、別個のスタンドアロン型ソリューションシリーズとしてますます評価されています。

アクセス管理とは、ユーザーが特定リソースにアクセスする権限を持っているかどうかを判断し、そのリソースに対して設定されたアクセスポリシーを適用できるようにする機能です。

アクセス管理は、IT管理者によって定義されたアクセスポリシーに基づいて実装されます。対象となる情報には、どのユーザーグループ（営業、研究開発、人事など）がどのクラウドアプリケーション（Salesforce、Office 365、Jira、Taleoなど）へのアクセスを許可されるかや、各アプリケーションにアクセスするために必要なユーザー属性（信頼できるネットワーク、パスワード、OTPなど）といったものが含まれます。

アクセスポリシーでは、クラウドアプリケーションの機密性に応じて、ユーザー属性をある程度評価する必要があります。これらの属性は、リスクベースまたはコンテキストベースの認証を使用して評価されます。このような認証は、クラウドアプリケーションごとに定義されたさまざまなアクセスポリシーを適用する上で中心的な役割を果たします。（詳細については、コンテキストベース認証の箇所をご覧ください。）

シングルサインオンもまた、クラウドアクセス管理において中心的な役割を果たします。シングルサインオンにより、単一のユーザー名とパスワードのセットまたは「ID」を使用して、すべてのクラウドアプリケーションにログインできるようになります。（詳細については、シングルサインオンの箇所をご覧ください。）

IDaaSとはIAM as a Serviceのことで、Identity as a Serviceとも呼ばれます。IDaaSとは、IDおよびアクセス管理向けに、クラウドベースのサービスとしての配信モデルを提供するIDおよびアクセス管理（IAM）ソリューションを意味します。近年では、IDaaSは別個の市場として見直されていますが、最近の市場動向を考慮すると、今後はアクセス管理とIGAの2つの別分野として扱われるようになると考えられます。その配信方法には、オンプレミスインストールのほか、ソフトウェアやクラウドベースのプラットフォームが含まれます。

IDガバナンスと管理（IGA）は、「誰がどのアプリケーションにアクセスできるべきか、または誰がどのアプリケーションへのアクセス権を持つのか」や、「実際には、誰が、誰によって、いつ、どのアプリケーションへのアクセスを許可されたのか」という質問に答えるのに役立つ一連の機能です。例えば、IGAソリューションは、研究開発スタッフがGitHub、Jira、Confluenceといった特定の開発アプリケーションにアクセスできるようにするのに役立つ場合があります。IGAソリューションは、研究開発グループのメンバーシップに基づいて、これらのアプリケーションへのアクセスを自動的にプロビジョニングできます。研究開発ユーザーは、他のアプリケーションへのアクセスのプロビジョニングを要求することもでき、このような要求は、一部のIGAソリューションでサポートされている管理承認プロセスを通して審査されます。

IDフェデレーションは、ユーザーの認証を管理する単一の信頼できるIDプロバイダー（IdP）に基づくアーキテクチャであり、アプリケーションは、ユーザーがそれらにアクセスを試みるたびに認証プロセスをIDプロバイダーに中継します。認証プロセスを信頼できるIDプロバイダーに中継するアプリケーションは、サービスプロバイダー（SP）と呼ばれます。

IDフェデレーションは、企業の内部・外部を問わず、多数のWebアプリ用の資格情報を個別に管理するという課題とフラストレーションを解決し、管理者とユーザーが複数のアプリケーションとITリソースに対して、単一のユーザー名とパスワードのセット（つまりID）を維持できるようにします。IDフェデレーションはパスワード疲れを解消し、セキュリティを向上させ、無数のパスワードを管理しなければならない問題を解決します。

IDフェデレーションは、SAMLやOpen ID Connectといったフェデレーションプロトコルや、MicrosoftのWS-Federationといった独自プロトコルに依存しています。

フェデレーションログインとは、ユーザーが既存の企業IDを使用して複数のアプリケーションにログインできるようにする、フェデレーションプロトコル（SAML、Open ID Connectなど）の機能です。例えば、異なるユーザー名とパスワードのセット、つまり「ID」を使用して別々のクラウドアプリケーションにログインする代わりに、フェデレーションログインを使用すると、ユーザーは、朝は企業ネットワークに、夜はVPNにログインするために使用するものと同じIDを使用してOffice 365、Salesforce、AWSなどにログインできます。

IDプロバイダーは、他の提携していないWebサイト（サービスプロバイダー）にアクセスしようとしているユーザーを認証するシステムです。IDプロバイダーは、サービスプロバイダーとともに、Webサイト（またはサービスプロバイダー）にアクセスしようとするユーザーを認証のためにIDプロバイダーに中継するIDフェデレーションアーキテクチャを構成します。IDプロバイダーは、ユーザーの認証データ（ユーザーのCookie、デバイス、ネットワーク、OTPなど）を検証し、「承認」または「拒否」の応答を生成して、サービスプロバイダーに送信します。IDプロバイダーは、別の提携していないWebサイトに代わって、特定のデータにアクセスするための承認を要求することもできます。承認データには、Webメールアカウントのメールアドレスや、ソーシャルネットワークアカウントの友達の名前といった情報にアクセスするための許可が含まれる場合があります。

例えば、SafeNet 認証サービスは、上記のシナリオのようにユーザーがクラウドアプリケーションにアクセスする際にIDプロバイダーとして機能します。

セキュリティトークンサービスは、他の提携していないWebサイトまたは「リライングパーティ」にアクセスしようとしているユーザーを認証するシステムです。セキュリティトークンサービスは、リライングパーティとともにセキュリティトークンサービスアーキテクチャを構成します。このアーキテクチャは、Webサイト（リライングパーティ）にアクセスしようとするユーザーを、認証のためにセキュリティトークンサービスに中継します。

セキュリティトークンサービスは、IDプロバイダーモデルまたはトークンベース認証とも呼ばれます。セキュリティトークンサービス（STS）はIDプロバイダーに相当し、リライングパーティ（RP）はサービスプロバイダーに相当します。また、SAMLアサーションの交換の代わりに、これらはセキュリティトークンと呼ばれます。名前は異なりますが、概念は同じです。

Security Assertion Markup Language（SAML / サムル）は、提携していないWebサイト間で認証データを交換するためのXMLベースのオープンスタンダードです。この交換機能は、IDフェデレーションまたはフェデレーション認証とも呼ばれています。

IDフェデレーションとは、ユーザーの既存の企業IDをクラウドに拡張し、ユーザーが既存の企業IDを使用してクラウドアプリケーションにログインできるようにする機能を意味します。SAMLを使用したクラウドアプリケーションへのフェデレーション認証により、ユーザーは既存の企業IDを使用してすべてのクラウドアプリケーションにログインできるため、多数のユーザー名とパスワードのセットを管理する代わりに、1つを維持するだけで済みます。

SAMLの仕組み
ユーザーがクラウドベースのアプリケーションにログインしようとすると、認証のために信頼できるIDプロバイダーにリダイレクトされます。IDプロバイダーは、ユーザーの資格情報（ユーザー名やワンタイムパスワードなど）を収集し、アクセスされているクラウドアプリケーションに応答します。この応答はSAMLアサーションと呼ばれ、SAMLアサーションには承認または拒否の応答が含まれます。

この応答に基づいて、サービスプロバイダー（Salesforce、Office 365、DropBoxなど）は、アプリケーションへのアクセスをブロックまたは許可します。

WS-Federation Services（WS-Fed）は、Microsoft独自のIDフェデレーションプロトコルです。WS-Fedは、MicrosoftのActive Directory フェデレーションサービス（AD FS）と連携して、Active Directoryに保存されているIDを、Office 365やAzureといったMicrosoft クラウドアプリケーションに拡張します。SAMLと同様に、WS-FedはIDプロバイダーモデルを使用します。Microsoft クラウドアプリケーションにアクセスすると、ユーザーは認証のためにAD FSにリダイレクトされ、ユーザーの応答に基づいて、クラウドアプリケーションはユーザーアクセスを許可または拒否します。

OAuth（オー オース）は、Open Authorizationの略で、提携していないWebサイト間でのフェデレーションまたは「トークンベース」の認証・承認のためのオープンスタンダードです。SAML、Open ID Connect、WS-Fedといった他のIDフェデレーションプロトコルと同様に、OAuthを使用すると、信頼できるIDプロバイダーによって検証されたIDを使用してアプリケーションにログインできます。OAuthは、フェデレーション認証の枠を超えて、ユーザーがリライングパーティのWebサイトに、連絡先名やEメールアドレスといった特定のアカウント情報へのアクセスを許可できるようにします。例えば、OAuthは、ソーシャルネットワークのWebサイトがユーザーのWebメールの連絡先にアクセスし、それらの連絡先をソーシャルネットワークに招待するかどうかをユーザーに尋ねるために使用されるプロトコルです。

OpenID Connectは、SAMLと同様に、IDプロバイダーモデルを使用するオープンスタンダードのIDフェデレーションプロトコルです。ただし、Cookieを使用して機能するため、ブラウザーで開くアプリケーション（ブラウザーベースのアプリケーション）でのみ機能するSAMLとは異なり、OpenID Connectは、ブラウザーベースのアプリケーション、ネイティブモバイルアプリ、デスクトップクライアント（リッチクライアントや一部のVPNなど）でのシングルサインオンの実装を可能にするシングルサインオンフレームワークを提供します。そのため、今日のほとんどのシングルサインオン実装は、クラウドベースとブラウザーベースのアプリのみをサポートしていますが、OpenID Connectを採用するIDプロバイダーが増えるにつれて、デスクトップクライアントやブラウザーベースのアプリケーション、ネイティブモバイルアプリなど、すべてのリソースへの同時アクセスを一度に認証できるようになります。

Bring Your Own Identity（BYOI：個人IDの持ち込み）は、他の場所で発行されたIDをサポートし、そのIDを使用してリソースへの安全なアクセスを可能にする企業やその他の組織の能力を説明するために使用される用語です。

ID管理の分野において、ベンダーや組織は、従業員やパートナーが各々のIDを使用して企業リソースにアクセスできるようにすることを目指しています。理論的にこのIDは、十分なレベルのID保証を提供する任意のIDのことを指し、例えば、政府発行のIDカードやヘルスケアスマートカードのほか、ソーシャルIDといったオンラインID、プロフェッショナルネットワークID、またFIDOといった商用IDが含まれます。企業と消費者の世界はより緊密に融合しており、カスタマーサービスで通常使われるものと同タイプの認証方法を実装しなければならないという企業のセキュリティチームのプレッシャーはますます高まっています。

IDブローカーは、ユーザーの既存ID（または任意の数の既存ID）を取得し、そのIDを使用して提携していないWebサイトへの認証を行うことをBYOIスキームに許可することで、BYOIスキームをサポートできるシステムです。例えば、IDブローカーは、ユーザーのソーシャルIDやWebメールIDをサポートし、そのユーザーが多数の提携していないWebサイトにアクセスできるようにします。IDブローカーを使用することで、企業は複数のIDプロバイダーをサポートすることができます。

シングルサインオン（SSO）とは、一度認証されると、その後にさまざまなリソースにアクセスする際に自動的に認証される機能のことです。SSOによって、ユーザーとターゲットアプリケーション間の仲介機能となり、個々のアプリケーションやシステムに個別にログインして認証を行う必要がなくなります。裏では、ターゲットアプリケーションとシステムは引き続き独自のクレデンシャルストアを維持し、ユーザーのシステムにサインオンプロンプトを表示します。SSOはこれらのプロンプトに応答し、資格情報を単一のログイン/パスワードのペアにマップします。（出典：Gartner）

SSOは、スタンドアロン型ソリューションであろうと、より広範なアクセス管理ソリューションであろうと、さまざまなIDフェデレーションプロトコルを介して実施できます。これには、SAML 2.0やOpenID Connectといったオープンソースプロトコル、MicrosoftのWS-Federationといった独自プロトコル、またパスワードボールトやリバースプロキシといったその他のテクノロジーが含まれます。

パスワードマネージャーとも呼ばれるパスワードボールトにより、レガシーアプリケーションやカスタムアプリケーションなど、ターゲットアプリケーションがIDフェデレーションプロトコルをサポートしていない場合に、シングルサインオン（SSO）機能を簡単に実行できます。パスワードボールトは、さまざまなWebサイトのパスワードを保存・暗号化することによって機能するシステムです。専用のパスワードを使用して各アプリケーションにログインする代わりに、ユーザーは（パスワードボールトを復号化する）マスターパスワードのみを使用して認証を行うことができ、異なるパスワードを管理する必要がなくなります。

承認とは、適切に認証されたユーザーが、リソースの所有者または管理者によって定義されたとおりに、アクセスが許可されているリソースにのみアクセスできるようにするプロセスです。カスタマーサービスの世界では、承認とは、クラウドベースのアプリケーション（ソーシャルネットワークなど）が、提携していないWebサイト（ユーザーのWebメールアカウントなど）上で特定の情報にのみアクセスすることをユーザーが保証するプロセスを指す場合もあります。

認証とは、ユーザーがアプリケーションやサービス、コンピューター、デジタル環境にログインする際に提供する資格情報に基づいて、ユーザーIDが検証されるプロセスです。ほとんどの認証用資格情報は、ユーザー名といったユーザーの所持情報と、パスワードといったユーザーの知識情報で構成されます。ユーザーによって提供された資格情報が、基盤となるアプリケーションやIDプロバイダーによって保存されている資格情報と一致する場合、ユーザーは正常に認証され、アクセスが許可されます。

コンテキストベース認証とは、ユーザーがアプリケーションにログインする際に評価される一連の補足情報に基づく認証方法です。最も一般的なタイプのコンテキスト情報には、ユーザーの所在地、時刻、IPアドレス、デバイスのタイプ、URL、アプリケーションのレピュテーションが含まれます。リスクベース認証や適応認証とも呼ばれるコンテキストベース認証は、認証の過程を可能な限り透過的かつ容易なものにすることを目的とするSSOおよびアクセス管理において、中核となる要素です。

コンテキスト（デバイス、役割、場所）あるいは動作ベースのもの（入力速度、ページビューシーケンスなど）のいずれであっても、ユーザーのログイン属性を評価することにより、シングルサインオンおよびアクセス管理ソリューションは、ユーザーに必要な認証レベルと、各アプリケーションによって定義されたアクセスポリシーとを継続的に合致させることができます。これにより認証は、すべての企業リソースに対して包括的かつ統一されたルールとしてではなく、アプリケーションのアクセスポリシーに従って、可能な限り摩擦のない方法できめ細かく適用されます。

継続認証とは、ユーザーが新しいアプリケーションやリソースにアクセスするたびに継続的に行われる認証方法です。単一アプリケーションへの1回のログインに対してのみ有効な1回限りの「はい/いいえ」の決定を行う、ワンタイム認証やバイナリ認証とは対照的です。

認証にはトークンやパスワード、指紋を使用し、基本的には「はい/いいえ」の決定が下されます。システムはユーザーのIDを検証し、アプリケーションへのアクセスを許可または拒否します。

しかし、コンテキストベース認証や行動バイオメトリクス（閲覧パターン、入力パターン、その他の物理的特性など）といった新しい技術により、認証はより継続的なプロセスになる可能性があります。IPアドレス、モバイルパラメータ、既知のデバイス、オペレーティングシステムといったさまざまな属性を評価することにより、コンテキスト認証またはリスクベース認証は、個人がアプリケーションにログインするたびにIDを継続的に検証できます。実際のところ、ユーザーが知らない状態でも動作できます。

コンテキスト認証は、個人のIDを検証するための摩擦のない方法を数多く提供します。これにより、ユーザーの利便性と、多数のクラウドアプリケーションにきめ細かなアクセス制御を適用する機能とのバランスを保つことが可能になります。そしてこれこそが、コンテキストベース認証に基づく継続認証の概念が、クラウドアクセス管理の基盤である理由です。