シングル・サインオン(SSO)とはSSOの仕組み

Art Wittman |コンテンツ・ディレクタ| 2024年10月22日

この記事の内容

私たちはつい、本当はやってはいけないことをやってしまいがちです。スマートフォンに保存したファイル、財布に入れたメモ、あるいは最悪の場合、キーボードの裏に貼った付箋紙に、ユーザー名とパスワードの一覧がある――そんなことはないでしょうか。さらには、「犬の名前＋いくつかの数字と記号」といった安易なパスワードの使い回しが習慣になっていたりします。

現代のウェブ中心の生活では、何十ものアカウント名とパスワードを管理しなければなりません。驚異的な記憶力でもない限り、それらをすべて異なるものにするのは難しいでしょう。実際には、シンプルで古く、もし誰かが本気で推測しようとすれば、当てられてしまう可能性が高いのです。これはサイバー犯罪者にとって絶好の機会であり、しかし100%防げる問題でもあります。

SSO(シングル・サインオン)とは

シングルサインオン技術は、私たちの仕事や私生活におけるパスワード問題に対する一つの部分的な解決策です。この技術を使うことで、認証サーバーに一度ログインするだけで、以降はそのサーバーが代わりに証明書を発行してくれ、対応するアプリに対して認証された資格情報として利用されます。

おそらく、皆さんもすでにこのようなシステムを使ったことがあるでしょう。「Appleでログイン」や「Googleでログイン」など、大手ベンダーのID管理システムを使って新たなパスワードを作成せずにWebアプリにログインしたことがあるなら、それがSSOの一例です。このSSOは、企業でもますます活用されており、多くの場合、他の認可技術と組み合わせて使われています。それにより、企業システムのセキュリティを確保しつつ、何十、何百というアプリケーションやサービスに対するパスワード管理の負担を現実的なレベルに抑えることができます。

主なポイント

  • SSOは、多数のパスワードとユーザー名の組合せを記憶する個人の負担を軽減します。
  • SSOは、ITチームにとっても管理する認証システムを一つに集約できるため、運用が容易になります。
  • SSOは、アプリケーションが、ネットワーク接続の管理やソフトウェアのアップデート確認など、自らの動作に必要なサービスに対してユーザーの認証を行うことを可能にします。

SSOの説明

シングル・サインオンの概念は簡単です。ユーザー名とパスワードを指定するか、使用する各アプリケーションを識別するかわりに、その情報を認証サーバーに1回のみ指定します。その後は、SSOシステムに参加しているアプリケーションにアクセスするたびに、認証サーバーがあなたの代わりに識別証明（認証トークンなど）を送信してくれる仕組みです。

SSOによって、知っておく必要があるユーザー名とパスワードの数が減ります。また、アプリケーションを使用するたびに認証情報の入力を求められる回数が大幅に減るため、より多くのアプリを手軽に使えるようになり、強力なパスワードを設定するモチベーションも高まります。企業のIT管理者の視点から見ると、SSOの導入によりセキュリティ手順のアップデートや、認証サーバー側により高度な認証機構（例：多要素認証、バイオメトリクスなど）を導入しやすくなります。その結果、すべてのSSO対応アプリケーションは個別の修正なしで、より安全な認証方式を利用できるようになります。

個人の生活においても、アプリごとに新しいユーザー名やパスワードを設定する代わりに、大手ベンダーの認証システムを使うことで多くの利点があります。最も大きなメリットの一つは、Apple や Google など、フェデレーテッド ID 管理サービスを提供する大手ベンダーは、パスワードや個人データを安全に保護する体制が整っている点です。一方で、新興のベンダーが提供するアプリケーションは、あなたが入力した認証情報を同じように安全に管理できるとは限りません。

SSOの仕組み

SSO（シングルサインオン）は、ユーザーが個々のアプリケーションに対して直接認証を行う代わりに、SSO サーバーに対して一度だけ認証を行う仕組みです。この認証プロセスが完了すると、SSO サーバーは、認証されたユーザーがアクセスしようとしているアプリケーションに対して証明書を提供します。この証明書は、ユーザーの身元を確認するためのものです。

これらの証明書は通常、一定期間のみ有効であり、ユーザーが認証を行った端末（システム）に紐づけられます。SSO システムに参加するには、アプリケーションが SSO サービスを利用できるように設計されている必要があります。企業においては、IT プランナーが特定の SSO モデルを選択し、それに基づいてすべてのアプリケーションが従業員の認証にそのモデルを使用するよう求めるのが一般的です。ただし、これには課題もあります。たとえば、ユーザーの認証情報を独自に保持する古いモノリシックなアプリケーションや、一般的な SSO アーキテクチャに対応していないアプリケーションは、SSO に統合するのが難しい場合があります。

デジタル・アクセスを簡素化するためのSSOの仕組み（図）
SSOがセキュリティを強化し、ユーザー・エクスペリエンスを向上させ、生産性を向上させる方法を示しています。

一般的なSSOの構成タイプ

一般的なSSO（シングルサインオン）の構成要素や概念には、集中型のアイデンティティ管理、標準化、強固なセキュリティ対策といった共通の特徴があります。なかでも重要なのは相互運用性です。つまり、複数のアプリケーション間で認証プロセスがスムーズかつユーザーフレンドリーに動作するように、各システムが連携できる必要があります。これが実現すれば、ITチームはより強固なパスワードポリシーや2要素認証の導入をスムーズに進められるようになります。

  • SAML。Security Assertion Markup Languageは、アプリケーションのユーザーの認証に役立つドキュメントの構造を記述した技術仕様です。SAMLでは、広く受け入れられているXML標準を使用して、アイデンティティ・サーバー(アイデンティティ・プロバイダとも呼ばれる)がアプリケーションを作成および送信するドキュメントの構造を指定します。これらのアプリケーションは、多くの場合、SSOパーランスの「サービス・プロバイダ」と呼ばれます。SAMLに対応している任意のアイデンティティプロバイダーが発行する認証情報は、SAML対応のアプリケーションであればどれでも利用できるため、SAMLはインターネットアプリケーションに適した選択肢となります。

    ただし、SAML自体には、アプリケーションが受け取る認証情報が改ざんされていないことを保証する仕組みは含まれていません。これは、別のセキュリティ技術によって補完されます。

  • Kerberos。Kerberosは、1980年代後半にMIT（マサチューセッツ工科大学）で進められたProject Athenaの一環として開発された、完全な認証および認可アーキテクチャです。Project Athenaの目的は、MIT構内の学生がネットワーク上のコンピュータリソースに普遍的にアクセスできる環境を構築することでした。当初、KerberosはData Encryption Standard（DES）を使用して、認証サーバーとアプリケーション間でやり取りされるメッセージを暗号化していました。48ビットの対称キーを使用していました。つまり、メッセージの暗号化と復号化に同じキーが使用されていました。当時、DESは米国国立標準技術研究所（NIST）によって維持される標準として最も安全な暗号方式とされていました。

    現在では、KerberosはDESに代わってNISTの新しい暗号化標準であるAdvanced Encryption Standard（AES）を使用しています。AESでは、長さが最大256ビットの長いキーが指定でき、複数のラウンドの暗号化が可能であるため、システムのクラッキングが非常に困難になります。

    Kerberosは対称鍵暗号を用いるため、鍵を管理する信頼された第三者の存在が必要となります。したがって、Kerberosは、使用ドメインが明確に設定されるエンタープライズ環境、たとえば企業のLANやVPNに最も適しています。インターネット上など、ドメインが事前に確立できない環境でKerberosを利用する場合は、開始時に公開鍵暗号を用いた別の認証方式が必要ですが、現実的にはそのような使い方はまれです。Kerberosは独自のクレデンシャル形式を使用することも、SAMLに対応するよう構成することも可能です。現在も広く使われており、たとえばMicrosoftでは、企業ネットワークにおけるデフォルトの認証方式として、よりセキュリティの低いNTLMではなくKerberosを採用しています。

  • OAuth。OAuthは、認証フレームワークを含まないオープンな認可フレームワークであり、インターネットアプリケーションがユーザーに代わって保護されたサービスのリソースへアクセスする必要がある場合にデフォルトで使用される仕組みです。Oracle Cloud Infrastructure(OCI)を搭載したOracleを含むほとんどのクラウド・プロバイダは、OAuthを使用して自社のクラウド・リソースへのアクセスを管理しています。オラクルでは、開発者がOAuthを利用したアプリケーションを簡単に作成できるようにするライブラリやサービスも提供しています。

    次に、OAuthシステムのコア・コンポーネントを示します。

    • クライアント・システム。通常は、インターネット上で使用可能な様々なサービスのリソースにアクセスするエンド・ユーザー・アプリケーションです。
    • 認可サーバー。クライアントが保護されたサービスにアクセスするためのトークンを要求するサーバーです。認可サーバーは、クライアントの認証証明書とともにトークンの要求を受け取り、リソース所有者によって認可されたアクセス・トークンを発行します。
    • リソース・サーバー。クライアントが使用しようとしている情報またはサービスを提供します。クライアントから有効なアクセス・トークンを受信すると、データまたはサービスが提供されます。

    アクセストークンによって指定されるアクセス権の種類は複数あり、必要とされる信頼レベルやクライアントデバイスの性質によって発行されるトークンの種類が異なります。たとえば、スマートテレビはノートパソコンとは異なるアクセス権限を受け取る場合があります。

  • OpenID Connect (OIDC)。OpenID Connectは、OAuthで使用するために構築されたアイデンティティ管理システムです。OIDCとOAuthは、Webベースのアプリケーションおよびモバイル・アプリケーションなどのインターネット・ネイティブ・システムに完全なSSO環境を提供します。OIDCでは、資格証明情報を返すための基礎としてSAMLを使用するのではなく、JSON Webトークン(後述)およびRESTfulプロトコルと呼ばれるJSONドキュメントを使用します。どちらもインターネットにネイティブで、開発者が簡単に使用できます。

    Kerberosのように対称キー暗号化を使用するのではなく、OIDCは公開キー暗号化を使用します。これにより、インターネットなどのドメインレス・ネットワークにメリットがあります。

  • スマートカード認証。OIDCなどのシステムでは、公開キー暗号化を使用して、認証中および認証後に、目的の受信者のみがアイデンティティ管理プロバイダと交換されたデータを参照できるようにします。公開鍵暗号は非対称暗号方式であり、誰でも利用可能な公開鍵と、秘密にされている秘密鍵を使います。公開鍵はメッセージを暗号化するために使われ、対応する秘密鍵でのみ復号できます。

    通常、秘密キーはユーザーのデバイスに格納されます。ほとんどのラップトップには、Trusted Platform Module (TPM)テクノロジを使用してシステム向けのメッセージを復号化する改ざん防止チップが付属しています。AppleやAndroidのスマートフォンも同様の技術を採用しており、AppleはSecure Enclaveと呼ばれ、AndroidはAndroid Knoxと呼ばれています。これらの技術により、デバイスは適切に要求された場合に自分の公開鍵を提供し、秘密鍵は外部に漏らさずにメッセージを復号します。

    これらのシステムの利点は、デバイスのユーザーがシステムでの暗号化の処理方法について何も知る必要がないことです。デメリットは、ユーザーが所有する各デバイスに一意の公開キー/秘密キー・ペアがあるため、デバイスは暗号化プロセスで個別に認識されることです。そのため、ノートパソコンやスマートフォンが紛失・盗難に遭い、かつ所有者のパスワードが知られてしまった場合には、そのデバイスの暗号化システムではアクセスを防げない可能性があります。

    この点で、クレジットカードに組み込まれているようなチップを搭載したスマートカードを使用すれば、どのデバイスを使用していても、1つの鍵ペアによって認証を行うことができます。スマートカードに搭載されたチップは独自のマイクロプロセッサであり、カードリーダーに差し込むか、近距離無線通信（NFC）などのRFID技術によって電力を供給・起動する必要があります。スマートカードによるセキュリティは、TPMチップによるセキュリティと同等の保護を提供します。

  • エンタープライズSSO。複雑なアプリケーション・インフラストラクチャを持つ大規模な組織では、ネットワークの境界に限定されたエンタープライズSSO (eSSO)システムを作成できます。従業員にとっては、業務に必要なアプリケーションへアクセスするために覚えるべきユーザー名やパスワードが1つか2つで済むという利便性があり、組織側にとってはシステムやデータに対するセキュリティをより効率的に管理できるというメリットがあります。これらのeSSOシステムでは、鍵の取り消しが容易であるという理由から共通キー暗号（対称キー暗号）を好む傾向があり、また、広く認知されている形式であるSAMLが採用されることも多くあります。加えて、エンドポイントのセキュリティを強化するために、さまざまな形式の多要素認証が導入されることも一般的です。

    SaaSアプリケーションの利用が広がる中で、企業は、OAuthのようにインターネット上で一般的に使用されている方式に移行するか、あるいは自社が採用しているeSSOフレームワークにSaaSアプリケーションを適合させるかを選択できます。SAMLは、エンタープライズ・ネットワーク内およびインターネット全体で使用できます。多くのSaaSアプリケーションは、ユーザー認証のために両方のフレームワークをサポートします。

  • Web SSO。Webアプリケーションは、ユーザーの操作を許可するためにOAuthを使用し、ユーザーを認証するためにOpenID Connectを利用することで、より良く機能するか、またはそれらの使用に限定される傾向があります。インターネット上での通信が前提とされているため、Web SSOシステムの構成要素はIETF（Internet Engineering Task Force）標準として定義されており、Web開発者が予想し、期待する形で機能するようになっています。さらに、認証と認可は密接に連携しており、RESTプロトコルなどのアクセス方式やJSONベースの情報標準を利用して、完全かつ拡張性のあるシステムを構築します。Web SSOシステムは、異なるドメイン間でも機能することを前提に設計されており、大規模な環境にも対応可能です。

  • LDAP。LDAPは1990年代に登場したプロトコルで、ユーザーがローカルネットワーク上のサーバーやプリンターといったリソースを検索・利用することを目的として設計されました。LDAPは、ドメイン内のすべてのリソースを把握している認証権限サーバーの存在を前提としているため、インターネット利用には適していません。

    LDAPはネットワークリソースへのアクセスを許可する際に使用されるため、LDAPサーバーにユーザーの認証情報（資格情報）を保存し、ユーザー認証機能も備えています。ただし、この認証メカニズムは強固とは言えず、たとえばパスワードがネットワーク上で平文のまま送信される仕様です。この弱点を補うために、SSL/TLSなど他のプロトコルによって暗号化を追加することがあります。

    LDAPの利点は、柔軟性と拡張性にあります。企業はLDAPを活用して、従業員に関する追加情報（所属組織、グループメンバーシップ、オフィス所在地、電話番号など）を保存できます。ただし、誰がどのデータにアクセスできるかといったより詳細なアクセス権限の管理にはLDAPだけでは対応が難しい場合があります。

  • JWT。JSON Webトークンは、構造化された方法でパーティ間で情報を安全に送信するために使用されるコンパクトなドキュメントです。JWTはSAMLドキュメントと同様の用途を果たしますが、より簡潔なフォーマットであり、URLに含めるのにも適しているという利点があります。JWTは、公開キー暗号方式を使って暗号学的に署名されることで、その正当性が保証されます。オープン認証(Oath)では、ユーザーが認証されると、アイデンティティ・サーバーはJSON IDトークンを返します。

    保護されたリソースにアクセスするための認可リクエストは、その後、JSONアクセス・トークンを返します。このトークンは、リソース・サーバーへのすべてのリクエストに含める必要があります。このようなトランザクションでは、クライアントの状態（この場合は「認証および認可された状態」）がリクエストに含まれるため、「RESTfulな通信」と呼ばれます。RESTとは「Representational State Transfer（表現状態の転送）」の略であり、この仕組みによって、リソースサーバーはクライアントごとにセッションを確立・維持する必要がなくなります。

    JWTはクリア・テキスト・ドキュメントであるため、HTTPS暗号化接続で使用する必要があります。トークンは通常、個人を特定できる情報などの機密データを含まないように設計されています。また、各トークンには国際標準の公開キー証明書形式であるX.509に基づいた署名が含まれており、リソースサーバーがその署名を検証することで、改ざんが行われていないことを確認できます。JWTは、OAuth/OpenIDベースの認証・認可システムの中核をなす要素であり、Webアプリケーションでの利用を想定して設計されています。スケーラビリティに優れ、複数のドメインをまたいでの利用にも適しています。

SSOの利点

IT部門やセキュリティ担当者は、SSO（シングルサインオン）を好む傾向があります。それは、SSOによってユーザー認証を集中管理でき、機密情報を保護し、エンタープライズシステムやアプリケーションとの統合管理が可能になるからです。彼らは通常、必要なユーザー教育や、継続的な監視・保守に積極的に取り組む姿勢を持っています。これは、SSOがもたらすいくつかの重要な利点に起因しています。

  • アクセスの一元化。SSOシステムは、ユーザーアカウントの管理や、多くのエンタープライズアプリケーションおよびクラウドプロバイダーが維持する各種アプリケーションへのアクセス管理の負担を軽減します。すべてのアプリケーションへのユーザー・アクセス権は、1箇所で付与および取り消すことができます。ユーザーのアクセス権を一元的に付与・取り消しできるため、例えば社員が退職した場合でも、各アプリケーションごとに個別に認証情報を削除する必要はありません。また、セキュリティ担当者は認証システムの設定変更を一箇所で行うことができ、個々のアプリケーションに対して変更を加える必要がなくなります。
  • セキュリティの向上。SSOは、従業員が記憶しなければならないユーザー名とパスワードの組み合わせ数を大幅に削減します。この負担が軽減されることにより、特にエンタープライズ環境では、多要素認証（MFA）や強力なパスワードポリシーといった、より高度な認証手段を導入しやすくなり、認証プロセス全体のセキュリティが向上します。
  • 従業員の生産性向上。SSOを導入すれば、従業員はユーザー名やパスワードを思い出すために苦労する必要がなくなります。一度認証されれば、通常は再認証なしで各種アプリケーションへアクセスできるため、従業員はより早く本来の業務に取りかかることができます。実装の詳細によっては、アプリケーションごとに再認証が必要な場合もありますが、少なくとも覚えておくべき認証情報はSSOのクレデンシャル一つだけになります。
  • パスワード疲れの軽減。正直なところ、多数のユーザー名とパスワードの組み合わせを管理するのは誰にとっても面倒です。複雑なパスワードを記憶しなければならない、しかも頻繁に変更しなければならない状況は、ストレスや不満を生みやすくなります。その結果、推測されやすいパスワードを使ったり、同じパスワードを複数のアカウントで再利用したり、パスワードをメモに書いてモニターに貼ってしまうような管理方法に頼る人も出てきます。SSOを導入することで、こうした負担を軽減できます。
  • 企業コンプライアンス。SSOは、上述のような一元的なアクセス管理のメリットを通じて、企業コンプライアンスを支援します。監査や是正措置も、SSOフレームワーク一つを確認すれば済むため、シンプルになります。
  • 統合の簡素化。典型的なエンタープライズ企業では、製造、サプライチェーン、財務、マーケティング、営業など、多数のデータベースインスタンスにペタバイト単位のデータを保存しています。たとえば、営業担当者が在庫データにアクセスできると便利ですが、それにはCRM（顧客管理）システムと在庫管理データベースの両方で本人が認証されている必要があります。SSOを利用すれば、リクエスト発行者の認証済みIDを提供でき、アクセス権限トークンを通じて、各ロールのユーザーがアクセス可能なデータを制御できます。SSOがなければ、CRMと在庫システムの統合ははるかに複雑になり、ユーザーには追加の認証ステップが必要になったり、在庫データのセキュリティが低下するリスクが高まったりします。
  • ユーザー・エクスペリエンスの向上。エンタープライズ・アプリケーションおよびWebアプリケーションに対する認証の必要性を減らすことで、ユーザー・エクスペリエンスが向上します。また、多くのユーザーは個人のオンライン活動でSSOに慣れているため、企業でSSOを導入してもトレーニングの必要性はほとんどありません。

SSOとセキュリティ: SSOは安全か?

まず最初に、「完全に安全」という状態は存在しません。存在するのは「セキュリティの度合い」です。そのうえで言えば、商業的に提供されているいかなるSSOフレームワークも、非常に高いセキュリティを備えています。それこそが、この技術の本質でもあります。一般的に、SSOシステム単体では完全なセキュリティソリューションとはなりません。むしろ、安全なIT環境を構成するうえでの重要なコンポーネントのひとつと捉えるべきです。SSOは、ユーザーを認証し、アプリケーションやその他のリソース提供システムに対して認証情報を供給するという役割を担うことで、全体的なセキュリティ戦略の中核を成しています。

SSOとプライバシー

SSOはプライバシーの向上に貢献しますが、その効果は実装方法によって異なります。たとえば、SAMLやJWTによる応答には、最低限として認証の主張（アサーション）が含まれます。さらに、ユーザーに適用されるグループやロール、実装者が提供することを選んだその他のデータも含まれる可能性があります。

ウェブベースの小売サイトやソーシャルメディアにおいては、アプリケーションがユーザーの年齢、所在地、その他の個人情報を知ることが役立つケースがあります。一般的に言えば、Facebookなどに個人情報を提供する場合、そのプライバシーポリシーに「提供しない」と明記されていない限り、またはアプリ側で特定情報の共有を拒否できる設定がない限り、Facebookがそれを他者に提供するものと考えておくべきです。

一方、企業環境においては、SSOシステムは認証アサーションに加え、そのユーザーが組織内で持つ役割（ロール）に関する情報を返すべきです。また、ユーザーの勤務先オフィスや社用電話番号といった情報も、ビジネス上有用であるため提供されることがあります。しかしそれ以外の情報については、取得がより困難であるべきです。何がデフォルトで提供されるかは、通常は人事部門のポリシーにより定められています。

SSOのユースケース

SSOは、ユーザーがひとつのログイン認証情報のみで複数のアプリケーションやシステムへシームレスにアクセスできるように設計されています。厳格な規制コンプライアンス要件を持つ組織では、追加のセキュリティ対策が必要となる場合もありますが、SSOはさまざまなシナリオで活用されています。代表的なユースケースは以下の通りです。

  • エンタープライズ・アプリケーション企業は通常、数十から数百のアプリケーションを管理し、それぞれがユーザーの認証を必要とします。アイデンティティ管理システムをアプリケーションごとに作成および保守することは、ユーザーまたはITチームにとって現実的ではありません。SSOを導入することで、従業員は一度の認証でログインし、その情報をもとに各種リソースへのアクセス権限を管理することが可能になります。

    認証のアサーションは、通常、特定の期間および単一のシステムでのみ有効です。従業員の社内における役割に関するより詳細な情報は、SSOシステム内で保持され、アプリケーションや認可システムがそれを参照して、アプリケーションやデータなどのリソースへのアクセスを限定的に提供します。

  • クラウドベースのアプリケーションビジネス用途でも一般消費者向けでも、クラウドベースのシステムには、エンタープライズ向けSSOシステムとは異なる認証および認可の要件があります。消費者にとっては利便性が優先され、一度認証されれば、同じデバイスからはその後も継続的にサービスを利用できる設計が一般的です。たとえば、Gmailにログインすると、再認証することなく、DocsやSheetsなどの他のGoogleアプリケーションを使用できます。ビジネスでは、SaaSアプリケーションまたはプラットフォームを提供するクラウド・サービス・プロバイダや、Infrastructure as a Serviceを提供するクラウド・サービス・プロバイダも、ユーザーのアイデンティティが確認されると、幅広いサービスへのアクセスが許可されます。この認証は、より大きなサービス認可スキームの第一ステップであり、ユーザーは一度ログインするだけで多くのサービスを利用できるようになります。どのサービスにアクセスできるかは、アプリケーションごとのユーザーの役割（たとえば、あるアプリでは管理者、別のアプリでは開発者、さらに別では一般ユーザー）や、組織が契約しているサービスの範囲によって決まります。アクセスは、組織が支払った金額にも依存します。

SSOの実装

社内にセキュリティの専門知識がないからといって、SSO（シングルサインオン）の導入をあきらめる必要はありません。マネージド・セキュリティ・サービス・プロバイダおよびSSOベンダー実装チームが支援します。多くの企業は、サードパーティ・プロバイダが提供するSSOサービスを使用することを選択しています。企業は高度な専門知識や先進的なセキュリティ機能、スケーラビリティの恩恵を受けることができ、ITチームはSSOの運用を専門家に任せることで、ビジネス成長の支援に集中できます。

高い視点で見たとき、SSO導入には次の3つの主要要素があります。

  1. ユーザー名やパスワードなどのエンド・ユーザー入力を安全に収集するクライアント認証システムの選択および配布。エンタープライズ環境であっても、こうしたシステムは一般的にWebページとして提供されるため、デバイスを問わず認証プロセスを一貫性のあるものにしやすいという利点があります。企業内では、ユーザーが社内ネットワークに接続しているか、VPN経由でアクセスしていることが条件になるのが一般的です。この要件により、組織は一元的かつ信頼性のあるID管理システムを構築できます。
  2. ユーザーを認証し、組織を代表して証明書を発行するIDマネージャの設定。多くの組織において、IDマネージャは、ユーザー認可トークンも発行できるシステムの一部として機能するか、認可サーバーと密接に連携しています。このトークンにより、アプリケーションは各ユーザーがアプリ内で何をできるのかを判断できるようになります。
  3. 独自のユーザーID管理システムの代わりに、SSOおよび認可システムからの証明書とトークンを使うようにアプリケーションを構成または変更。

SSOのベストプラクティス

社内での導入であれ、サードパーティの支援を受ける場合であれ、あるいはサービスとしてのSSOを利用する場合であれ、成功するにはいくつかのポイントがあります。以下はその代表的なものです。

  1. 多要素認証（MFA）の導入を必須にする。SSOを導入することで、パスワードポリシーを単一のフレームワークから一括で適用できるようになるだけでなく、「多要素認証（MFA）」と呼ばれる強力な本人確認技術を組み合わせて導入することも可能になります。多要素認証の手段には、スマートカード、スマートフォン上で動作するアプリ、生体認証の各種形式などが含まれます。
  2. ロールベースのアクセス制御（RBAC）を活用する。ユーザーを認証するだけでは、エンタープライズリソースへのアクセス管理の問題は解決しません。もう一つの課題は、「ユーザーが許可されたリソースだけにアクセスできるようにする」ことです。そのために、「マーケティング」「財務」「製造」「営業」などのグループを定義し、それぞれのグループ内でユーザーに対して役割（ロール）を設定することで、アクセス制御を細かく調整しつつ、管理も一元化できます。
  3. 監査と標準の更新を行う。認証を単一のメカニズムのフレームワークに集約することで、監査や、新たな基準に対応するための更新プロセスが大幅に簡素化されます。
  4. ロールと権限の管理を実装する。SSOは、ゼロトラストを前提としています。ユーザーは自身の業務に必要なリソースにのみアクセスでき、閲覧できる情報も明示的に許可されたものだけに制限されるべきです。
  5. データ・プライバシ法に準拠する。SSO フレームワークを使用しても、データプライバシー法の遵守が保証されるわけではありませんが、その遵守の達成と実証がはるかに容易になります。

Oracleでアクセスを安全かつ容易に制御

Oracle Cloud Infrastructure(OCI)とクラウドおよびオンプレミス・アプリケーションのユーザー・アイデンティティとアクセスを管理する必要がありますか？ゼロトラスト・セキュリティ戦略を追求している組織の場合、Oracle Cloud Infrastructure Identity and Access Management (IAM)には、必要な管理および統合ツールが用意されています。

多要素認証をサポートするユニバーサル・オーセンティケータのデプロイに関心がありますか？Oracle Access Managementは、オンプレミスまたはクラウドで実行できる柔軟なシステムを提供します。組織は、これらのポリシーがデバイスや場所に関わらずユーザーをフォローできるようにすることで、時間や場所、デバイスの種類に関わらず、データへのアクセスを安全に保護できます。MFAに加え、OracleのIAM製品群は、信頼できるデバイスによるSSOおよびアプリケーションSSOをサポートしており、ゼロトラスト・アーキテクチャの原則と要件を実現するために不可欠な機能を提供します。

企業が利用するアプリケーション数が増えるにつれ、またそれらのアプリケーションがさまざまなサービスやデータソースに依存するようになる中で、ユーザー認証および認可の管理はますます複雑になります。SSOフレームワーク を導入することで、エンドユーザーとアプリケーションアーキテクトの双方にとって認証と認可のプロセスがシンプルになり、管理の効率化とセキュリティの強化を同時に実現できます。

AIは、生体認証、異常検出、プロビジョニングなどの機能により、SSOシステムの機能とセキュリティを大幅に強化できます。AIプログラムをセキュアかつコスト効率よく稼働させる方法をご紹介します。

SSOのFAQ

SSOは何を表していますか。

SSOはシングル・サインオンを表します。

SSOアカウントとは何ですか。

SSO アカウントとは、1 組のログイン資格情報で複数のアプリケーションやシステムにアクセスできるようにする集中認証サービスです。つまり、組織が提供するすべてのサービスやリソースにアクセスするために、ユーザー名とパスワードをそれぞれ 1 つずつだけ覚えておけばよいということです。SSO アカウントは、ログインプロセスを簡素化し、セキュリティを向上させ、ユーザーが業務に必要な情報やツールにアクセスしやすくします。

SSOの例を教えてください。

コンシューマー向けでは、Amazon、Google、Meta、Microsoft などの大手ベンダーが、他のアプリケーションのユーザー認証情報のソースとして機能することができます。資格情報を入力するか、上記のいずれかのサービスを使ってログインするかを選べるダイアログボックスが表示されたことがある場合、それは SSO を利用している例です。