Gemalto is now part of the Thales Group, find out more.
お問い合わせ

アクセス管理に関する FAQ

アクセス管理の概念に関する参照情報

企業は、便宜と効率化を図るためにクラウド アプリケーションを採用すると、気づかぬうちにリスクも高まることになります。機密性のあるアプリケーションやデータは、デフォルトでは脆弱で静的なパスワードによって保護されます。誰が、何に、いつアクセスしているかと、そのユーザ ID の検証方法に対する可視性を実現することは困難で、コンプライアンスも徹底できません。クラウド ID を管理するために、IT 管理者には多数の異なるコンソールが必要になります。また、このプロセスで最も重要なユーザは、無数のユーザ名とパスワードを管理しなければならなくなります。

アクセス管理 - ハンドブック

アクセス管理ハンドブック

クラウド シングル サインオンときめ細かなセキュリティを利用してユーザ アクセスを管理していますか?

アクセス管理ハンドブックのダウンロード

アクセス管理は、こうした切迫した課題を解決して、セキュアで使いやすく、すべての標準に準拠したクラウドを採用できるようにすることを目的とした分野です。

Gemalto のアクセス管理に関する 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 など) が必要か、といった情報が含まれます。

アクセス ポリシーでは、クラウド アプリケーションの機密性に応じて、多数または少数のユーザ属性の評価が必要とされることがあります。これらの属性は、各クラウド アプリケーションに対して定義された異なるアクセス ポリシーを適用するために中心的な役割を果たすリスク ベース認証またはコンテキスト ベース認証を使用して評価されます (詳細については、コンテキスト ベース認証の説明を参照してください)。

クラウド アクセス管理で中心的な役割を果たすもう 1 つの機能は、シングル サインオンです。これにより、単一のユーザ名とパスワードの組み合わせ (「ID」) を使用して、そのユーザのすべてのクラウド アプリケーションにログインできます (詳細については、シングル サインオンの説明を参照してください)。

IDaaS とは、IAM as-a-Service であり、identity-as-a-service とも呼ばれます。IDaaS は、ID/アクセス管理のためにクラウド ベースのアズ ア サービス デリバリー モデルを提供する ID/アクセス管理 (IAM) ソリューションです。近年、IDaaS は単一の市場とみなされてきましたが、最近の市場の傾向からすると、今後は 2 つの個別の分野 (アクセス管理と IGA) として扱われるようになるものと予想されます。そして、それらのデリバリー方式としては、たとえばオンプレミスでの導入、ソフトウェア、クラウド ベース プラットフォームなどが考えられます。

IDaaS の図

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 連携図とは何ですか?

連携ログインとは、ユーザが現在の企業 ID を使用して、複数のアプリケーションにログインできるようにするための連携プロトコル (SAML、Open ID Connect など) の機能です。 たとえば、個々のクラウド アプリケーションにそれぞれ異なるユーザ名とパスワードの組み合わせ (「ID」) を使用してログインするのではなく、連携ログインを利用すれば、ユーザは朝に企業ネットワークにログインするために、または夜に VPN にログインするために使用したのと同じ ID で、Office 365、Salesforce、AWS などにログインできます。

ID プロバイダとは、関連付けられていない他の Web サイト (「サービス プロバイダ」) へのアクセスを試みているユーザを認証するシステムです。ID プロバイダは、サービス プロバイダとともに、ID 連携アーキテクチャを構成します。このアーキテクチャにより、Web サイト (サービス プロバイダ) へのアクセスを試みているユーザは、認証を受けるために ID プロバイダに中継されます。ID プロバイダは、ユーザの認証データ (ユーザの Cookie、デバイス、ネットワーク、OTP など) を検証し、「許可」または「拒否」のレスポンスを生成します。そして、そのレスポンスがサービス プロバイダに送信されます。ID プロバイダは、関連付けられていない別の Web サイトの代わりに、特定のデータにアクセスするための認可を要求することもできます。認可データには、Web メール アカウントの電子メール アドレスまたはソーシャル ネットワーク アカウントの友人の名前などの情報に対するアクセス許可が含まれることがあります。

たとえば、SafeNet 認証サービスは、ユーザが上記のシナリオでクラウド アプリケーションにアクセスする場合に、ID プロバイダとしての役割を果たします。

ID プロバイダ モデル図

セキュリティ トークン サービスとは、関連付けられていない他の Web サイト (「Relying Party」) へのアクセスを試みているユーザを認証するシステムです。セキュリティ トークン サービスは、Relying Party と共にセキュリティ トークン サービス アーキテクチャを構成します。このアーキテクチャにより、Web サイト (Relying Party) へのアクセスを試みているユーザは、認証のためにセキュリティ トークン サービスに中継されます。

セキュリティ トークン サービスは、ID プロバイダ モデルまたはトークン ベースの認証とも呼ばれます。 セキュリティ トークン サービス (STS) は ID プロバイダと同等であり、Relying Party (RP) はサービス プロバイダと同等です。また、STS では、SAML アサーションを交換する代わりに、セキュリティ トークンと呼ばれるものを交換します。名前は異なりますが、コンセプトは同じです。

Security Assertion Markup Language (SAML: サムルと読みます) とは、関連付けられていない Web サイト間で認証データを交換するための XML ベースのオープン標準であり、ID 連携または連携認証とも呼ばれる機能です。

ID 連携とは、ユーザの現在の企業 ID をクラウドに拡張して、ユーザが現在の企業 ID でクラウド アプリケーションにログインできるようにする機能です。SAML に対応したクラウド アプリケーションへの連携認証を使用すると、ユーザは、現在の企業 ID ですべてのクラウド アプリケーションにログインすることができます。これにより、ユーザは、5~25 ものユーザ名とパスワードの組み合わせを管理する必要がなくなり、1 つのユーザ名とパスワードを管理するだけで済むようになります。

SAML の仕組み
ユーザは、クラウド ベース アプリケーションへのログインを試みたときに、認証を得るために信頼できる ID プロバイダにリダイレクトされます。 ID プロバイダは、そのユーザのクレデンシャル (ユーザ名とワンタイム パスワードなど) を収集し、アクセス対象のクラウド アプリケーションにレスポンスを返します。このレスポンスは SAML アサーションと呼ばれ、SAML アサーションには許可または拒否を示すレスポンスが含まれます。

このレスポンスに基づいて、サービス プロバイダ (Salesforce、Office 365、DropBox など) は、アプリケーションへのアクセスをブロックするか、許可します。

ID プロバイダ モデル図

 

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

Open Authorization の略語である OAuth (「オーオース」と読みます)は、連携認証または「トークン ベース」の認証と、関連付けられていない Web サイト間の認可のためのオープン標準です。 SAML、Open ID Connect、WS-Fed などの他の ID 連携プロトコルと同様に、OAuth を利用すると、信頼できる ID プロバイダによって検証される ID でアプリケーションにログインできます。OAuth では、特定のアカウント情報 (担当者の名前や電子メール アドレスなど) へのアクセスを、Relying Party の Web サイトに許可することができます。これは、連携認証にはない機能です。たとえば、OAuth は、ソーシャル ネットワークの Web サイトで Web メールの連絡先にアクセスして、Web メールの連絡先に含まれる人物をソーシャル ネットワークに招待するかどうかを確認するために使用されます。

OpenID Connect は、SAML と同様の、ID プロバイダ モデルを採用したオープン標準 ID 連携プロトコルです。ただし、OpenID Connect は、Cookie を使用していて、ブラウザで開かれるアプリケーション (「ブラウザ ベース アプリケーション」) のみで動作する SAML とは異なり、ブラウザ ベース アプリケーション、ネイティブ モバイル アプリ、デスクトップ クライアント (リッチ クライアントや一部の VPN など) にわたりシングル サインオンを実装できるシングル サインオン フレームワークを提供します。今日のほとんどのシングル サインオンの実装ではクラウド ベースとブラウザ ベースのアプリケーションのみをサポートしていますが、OpenID Connect を採用する ID プロバイダが増えるにつれて、デスクトップ クライアント、ブラウザ ベース アプリケーション、ネイティブ モバイル アプリのいずれであろうと、1 回の認証だけですべてのリソースに同時にアクセスできるようになることでしょう。

BYOI (Bring Your Own Identity) とは、企業またはその他の組織が、他の場所で発行された ID をサポートし、その ID を使用してリソースへのセキュアなアクセスを実現する機能を示す用語です。

ID 管理の分野において、ベンダーと組織は、従業員とパートナーが自身の ID を使用して企業のリソースにアクセスできるようにしようとしています。 理論上、この ID は、十分なレベルの身分証明を提供する任意の ID にすることができます (たとえば、ソーシャル ID、プロフェッショナル ネットワーク ID、FIDO のような商業的に利用可能な ID などのオンライン ID のほか、政府が発行する ID カード、医療スマート カードなど)。 エンタープライズ セキュリティ チームは、消費者向けサービスで一般に見られるものと同じタイプの認証方法を実装する必要にますます迫られており、企業向け環境と消費者向け環境の融合が進んでいます。

 

ID ブローカーとは、ユーザの既存の ID (または任意の数の既存の ID) を取得し、その ID を使用して関連付けられていない Web サイトの認証を許可することにより、BYOI 方式をサポートできるシステムです。たとえば、ID ブローカーは、ユーザのソーシャル ID または Web メール ID をサポートして、関連付けられていない多数の Web サイトへのアクセスをそのユーザに許可することができます。ID ブローカーを使用すると、組織は複数の ID プロバイダをサポートできます。

ID ブローカー図とは何ですか?

 

シングル サインオン (SSO) では、1 回認証されれば、その後さまざまなリソースにアクセスするときに、自動的に認証されます。 各アプリケーションとシステムに個別にログインして認証される必要をなくし、ユーザと対象のアプリケーションとの実質的な仲介役を果たします。バックグラウンドで、対象アプリケーションとシステムは、引き続き独自に保存されたクレデンシャルを維持し、ユーザのシステムに対してサインオンを要求します。SSO はそうした要求に応じて、シングル サインオンのログイン/パスワードの組み合わせとクレデンシャルを対応付けます(出典: Gartner)。

スタンドアロン ソリューションであるか、より幅広いアクセス管理ソリューションであるかにかかわらず、SSO は一連の ID 連携プロトコルを通じて実現できます。 たとえば、SAML 2.0 や Open ID Connect などのオープン ソース プロトコル、Microsoft の WS-Federation などの独自のプロトコル、パスワード ボールトやリバース プロキシなどの他のテクノロジです。

パスワード マネージャとも呼ばれるパスワード ボールトは、ターゲット アプリケーション (レガシー アプリケーションやカスタム アプリケーションなど) が ID 連携プロトコルをサポートしていない場合に、シングル サインオン (SSO) を実現するためのシンプルな方法です。パスワード ボールトは、異なる Web サイトのパスワードを保存し暗号化することによって動作するシステムです。ユーザは、専用のパスワードで各アプリケーションにログインする代わりに、(パスワード ボールトを復号する) マスター パスワードで簡単に認証を受けることができます。これにより、個別にパスワードを保管する必要がなくなります。

認可とは、正しく認証されたユーザが、リソースのオーナーまたは管理者が定義した、アクセスを許可されたリソースのみにアクセスできるようにするプロセスです。消費者向けの環境の場合、認可は、クラウド ベース アプリケーション (ソーシャル ネットワークなど) が、関連付けられていない Web サイト (ユーザの Web メール アカウントなど) の特定の情報のみにアクセスできるようにするプロセスを指すこともあります。

認証とは、アプリケーション、サービス、コンピュータ、デジタル環境へのログイン時に、ユーザの ID がユーザの提供するクレデンシャルに基づいて検証または確認されるプロセスです。 ほとんどの認証クレデンシャルは、ユーザに割り当てられている情報 (ユーザ名など) とユーザが知っている情報 (パスワードなど) で構成されます。ユーザによって提供されたクレデンシャルが、基盤アプリケーションまたは ID プロバイダによって保存されているクレデンシャルと一致した場合、ユーザは認証され、アクセスを許可されます。

コンテキスト ベース認証とは、ユーザがアプリケーションにログインするときにアクセスされる一連の補足情報に基づく認証方式です。特に一般的なタイプのコンテキスト情報には、ユーザの場所、時間、IP アドレス、デバイスのタイプ、URL、アプリケーションの評価などがあります。 コンテキスト ベース認証は、リスク ベース認証 (Adaptive Authentication) とも呼ばれ、SSO とアクセス管理の分野で中心的な役割を果たします。その目的は、認証手続きをできる限り透過的かつ簡単にすることです。

シングル サインオン ソリューションとアクセス管理ソリューションでは、コンテキスト (デバイス、役割、場所) または行動ベース (タイピング速度、ページの表示順序など) のいずれであるかにかかわらず、ユーザのログイン属性にアクセスすることにより、ユーザから要求された認証レベルと各アプリケーションに対して定義されたアクセス ポリシーを継続的に一致させることができます。この方法により、すべてのエンタープライズ リソースに対する包括的かつ統一的なルールではなく、各アプリケーションのアクセス ポリシーに従って、認証ができる限りスムーズな方法できめ細かく適用されます。

継続認証とは、単一のアプリケーションに対して 1 回のログインのみで有効な 1 回限りの許可/拒否を決定するワンタイム認証やバイナリ認証とは対照的な、ユーザが新しいアプリケーションやリソースにアクセスするたびに継続的に実行される認証の形式です。

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

ただし、コンテキスト ベース認証や行動的生体認証 (閲覧パターン、入力パターン、その他の物理的な特徴など) のような比較的新しいテクノロジによって、認証をより継続的なプロセスにすることが可能です。コンテキスト ベース認証またはリスク ベース認証では、IP アドレス、モバイル パラメーター、既知のデバイス、オペレーティング システムなどの一連の属性にアクセスすることにより、ユーザがアプリケーションにログインするたびに、そのユーザの ID を継続的に確認することができます。実際、認証はユーザに対して透過的に実行することさえできます。

コンテキスト ベース認証は、ユーザの ID をスムーズに確認するためのさまざまな方法を提供します。これにより、ユーザの便利さと、多数のクラウド アプリケーションに対するきめ細かなアクセス制御を適用する機能とのバランスを取ることができます。このため、コンテキスト ベース認証に基づく継続認証の概念が、クラウド アクセス管理の基礎となります。

お問い合わせ

 

セーフネットへご関心をお持ちいただき、有難う御座います。セーフネットへのお問い合わせにつきましては、当フォームに必要事項をご記入いただき、SUBMITボタンをクリックして頂きますようお願い申し上げます。弊社担当者よりご連絡させて頂きます。

 

お問い合わせフォーム

* メールアドレス:  
* 名:  
* 姓:  
* 企業名:  
* 電話番号:  
* 国:  
* State (US Only):  
* Province (Canada/Australia Only):  
* 市町村  
コメント:  
 


Submit(送信)ボタンをクリックすることにより、私はジェムアルトのプライバシーポリシーに記載されている通り、ジェムアルト及びその関連会社から情報を受け取ることに同意します。