シングルサインオン（SSO）とは何か？その仕組みとは？

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

この記事の内容

誰もが一度は、やってしまうこと。スマートフォンの中や財布の中に、あるいは最悪の場合、キーボードの裏に貼った付箋に、ユーザー名とパスワードの一覧をメモしている――そんな経験はないでしょうか。さらに、ペットの名前に数字と記号を少し足しただけのパスワードを使うこともよくあります。

現代のウェブ社会を生きる私たちは、たくさんのアカウント名とパスワードを管理しなければなりません。驚異的な記憶力の持ち主でない限り、全部のパスワードを違うものにするのは難しいものです。ほとんどのパスワードはシンプルで、使い古されたものであり、もし誰かが本気で調べれば、容易に推測されてしまう場合があります。これはサイバー犯罪者にとっては絶好の機会ですが、実はこうしたリスクは完全に防ぐことができるのです。

シングルサインオン（SSO）とは

シングルサインオン技術は、仕事でもプライベートでも悩みの種となるパスワード問題の部分的な解決策です。この仕組みを使うことで、一度認証サーバーにログインすれば、その後はサーバーが私たちの代わりに証明書を発行し、対象アプリにおいて認証済みの資格情報として利用されます。

あなたもこうしたシステムを利用した経験がきっとあるはずです。たとえば、「Appleでサインイン」やGoogle、またはその他大手ベンダーのID管理システムを使って新たなパスワードを作成せずにWebアプリケーションにログインする場合、これがSSOです。SSOは企業の現場でも急速に導入が進んでおり、しばしば他の認可技術と組み合わせて活用されています。これにより、エンタープライズシステムのセキュリティ確保と、数十から数百にわたるアプリケーションやサービスのパスワード管理を現実的なものにしています。

主なポイント

  • SSOは、個人が多くのパスワードやユーザー名の組み合わせを覚える負担を軽減します。
  • SSOは組織全体に対して、IT部門が管理すべき認証システムを1つにまとめることで、管理業務を効率化します。
  • SSOはまた、アプリケーションがネットワーク接続の管理やソフトウェアアップデートの確認など、必要なサービスに対してユーザー認証を行う際にも役立ちます。

SSOの基本

シングルサインオンの考え方は非常にシンプルです。利用する各アプリケーションごとにユーザー名やパスワードを入力して自身を認証するのではなく、一度だけ認証サーバーにその情報を入力します。それが完了すると、認証サーバーが、SSOシステムに参加しているアプリケーションへアクセスするたびに、あなたに代わって識別証明を送信します。

SSOにより、覚えておくべきユーザー名やパスワードの数が大幅に減ります。また、認証情報の入力を求められる回数も著しく減少し、多様なアプリケーションをより簡単に利用できるようになります。このことで、より強固なパスワードを設定できる可能性も高まります。エンタープライズIT担当者の視点から見ると、SSOを導入することで、認証サーバー側でより高度な認証メカニズムを採用できるようになり、それに伴って全ての連携アプリケーションが変更なしで、より安全な認証プロセスを利用できるようになります。

プライベートな利用においては、各アプリごとに新たなユーザー名やパスワードを作成するのではなく、大手ベンダーの認証システムを利用することで、さまざまなメリットがあります。特に大きな利点として、フェデレーションID管理サービスを提供する大手ベンダーは、顧客から預かったパスワードや個人情報の保護に優れていることが挙げられます。一方で、新規ベンダーの新しいアプリケーションでは、あなたが入力した認証情報が十分に保護されない可能性もあります。

SSOの仕組み

SSOは、利用者がそれぞれのアプリケーションに対してではなく、SSOサーバーに対して一度だけ認証を行う仕組みです。認証が完了すると、SSOサーバーは、認証されたユーザーがアクセスしようとするアプリケーションに証明書を発行します。この証明書が、ユーザーの身元を証明する役割を果たします。

証明書は通常、一定期間のみ有効であり、認証を実施した端末やシステムに紐付けられます。SSOを利用するためには、アプリケーション側でこのサービスを利用できるように設計されている必要があります。企業内では、IT担当者が特定のSSOモデルを採用し、すべてのアプリケーションがそのモデルを使って従業員の認証を行うよう求めるのが一般的です。従来型で独自のユーザー認証情報を管理している、あるいは一般的なSSOアーキテクチャに対応していない古いアプリケーションの場合、こうした統一が難しくなる場合があります。

SSOがデジタルアクセスを簡易化する仕組み（図）
SSOは上記のようにセキュリティ、ユーザー・エクスペリエンス、生産性の向上に貢献します。

共通のSSO構成タイプ

共通のSSOコンポーネントや概念は、「集中管理されたID管理」「標準化」「堅牢なセキュリティ対策」など、いくつかの特徴を共有しています。重要なのは相互運用性です。これらのシステムは連携して動作し、認証プロセスが複数アプリ間でも使いやすくスムーズに動く必要があります。これが実現すれば、ITチームは最小限の反発で、より強固なパスワードや多要素認証を義務付けることができます。

  • SAML： Security Assertion Markup Languageは、ユーザーをアプリケーションに認証するためのドキュメント構造を定義する技術仕様です。SAMLは広く受け入れられているXML標準を使い、IDサーバー（IDプロバイダーとも呼ばれます）が作成してアプリケーションに送る、ドキュメント構造を指定します。これらのアプリケーションは、SSO用語では「サービスプロバイダー」と呼ばれることが多いです。SAMLを利用する任意のIDプロバイダーは、SAML対応アプリケーションで使用できる認証資格情報を作成できるため、インターネットアプリケーションに適しています。

    SAML自体には、アプリケーションが受け取る認証情報が改ざんされていないことを保証する仕組みはありません。それは他の技術で対処する必要があります。

  • Kerberos： Kerberosは、1980年代後半にMITでProject Athenaの一環として開発された、完全な認証・認可アーキテクチャです。Project Athenaは、MITの学生がキャンパス内のあらゆる場所でコンピュータリソースにアクセスできるネットワークの構築を目指していました。Kerberosは当初、認証サーバーとアプリケーション間でやりとりされるメッセージを暗号化するためにDES（データ暗号化標準）を使用していました。ここでは、48ビットの共通鍵（シンメトリック鍵）が使用されており、暗号化と復号に同じ鍵を使っていました。当時、DESはNIST（米国国立標準技術研究所）規定の中で最も安全な標準的暗号方式でした。

    現在では、KerberosはDESに代わるNISTの暗号標準であるAdvanced Encryption Standard（AES）を使用しています。AESは最大256ビットまでのより長い鍵を指定でき、複数回の暗号処理を行うため、非常に解読が困難です。

    Kerberosは共通鍵暗号方式を使用するため、鍵の管理を行う信頼できる第三者が必要となります。そのため、特定の利用ドメインを厳格に構築できるエンタープライズアプリケーション、通常は企業のLANやVPNなどの環境での利用に最適です。Kerberosは、ドメインが確立されていないインターネット環境においても、公開鍵暗号という別の認証方式を用いてプロセスを開始することで利用可能ではありますが、この方法で採用されることは稀です。Kerberosは独自の認証フォーマットを使うことも、SAMLを利用するよう構成することも可能です。Kerberosは今でも人気があり、マイクロソフトもエンタープライズネットワークにおいて、より安全なKerberosをNTLM認証の代わりに採用しています。

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

    以下はOAuthシステムの主な構成要素です。

    • クライアントシステム：一般的には、インターネット上でさまざまなサービスのリソースへアクセスしたいエンドユーザーのアプリケーションを指します。
    • 認可サーバー：クライアントが保護されたサービスへアクセスするためのトークンの発行を依頼するサーバーです。認可サーバーは、トークンのリクエストとともにクライアントの認証証明書を受け取り、リソース所有者により認可されたアクセストークンを発行します。
    • リソースサーバー：クライアントが利用しようとする情報を持つ、またはサービスを提供するサーバーです。クライアントから有効なアクセストークンを受け取った場合に、データやサービスを提供します。

    アクセストークンでは、さまざまなアクセス権限タイプを指定できます。どの種別のアクセストークンを発行するかは、要求される信頼レベルやクライアントデバイスの性質に応じて決まります。たとえばスマートテレビは、ノートパソコンとは異なるアクセス許可を受ける可能性があります。

  • OpenID Connect (OIDC)： OpenID Connectは、OAuthと組み合わせて利用されるID管理システムです。OIDCとOAuthを併用することで、Webアプリケーションやモバイルアプリケーションなど、インターネットネイティブなシステムに対し、フル機能のSSO環境を提供できます。証明情報のやりとりにSAMLを使う代わりに、OIDCはJSON Web Token（JWT）と呼ばれるJSON形式のドキュメントや、RESTfulプロトコルを利用します。これらはインターネット標準であり、開発者にとって扱いやすい点が特長です。

    また、Kerberosのように共通鍵暗号方式を使うのではなく、OIDCでは公開鍵暗号方式を用いています。これにより、インターネットのような特定のドメインに依存しないネットワーク環境にも柔軟に対応できます。

  • スマートカード認証：OIDCのようなシステムは、公的鍵暗号方式を用いて、認証中およびその後に、ID管理プロバイダーとやり取りされるデータが意図した受信者以外には見られないようにします。公開鍵暗号方式は非対称型で構成されており、公開鍵はクライアントやサーバーに送信するメッセージの暗号化に利用され、秘密鍵は極秘扱いとされ暗号化されたメッセージの復号に使われます。

    通常、秘密鍵はユーザーのデバイスに保存されます。多くのノートパソコンには、Trusted Platform Module（TPM）技術を利用した改ざん防止チップが搭載されており、システム宛ての暗号化メッセージの復号に使用されます。AppleやAndroidのスマートフォンにもこれらと似た仕組みが用意されており、Appleは「Secure Enclave」、Androidは「Android Knox」と呼ばれる機能を備えています。これらの技術により、デバイスは正しく要求されれば公開鍵を提供し、決して外部に開示されない秘密鍵を使って受信データを復号できます。

    こうした仕組みの利点は、ユーザー自身が暗号の仕組みを知らなくても利用できることです。一方で欠点としては、所有する各デバイスごとに固有の公開鍵／秘密鍵ペアが生成されるため、暗号化の仕組みの中で個別のデバイスとして認識されることになります。仮にノートパソコンやスマートフォンが紛失や盗難に遭い、さらに盗んだ人物が所有者のパスワードを知っていた場合、暗号化システムだけではアクセス防止はできません。

    クレジットカードなどに搭載されているチップと類似したチップが搭載されたスマートカードを使えば、利用するデバイスに関わらず１組の鍵セットでユーザー認証が行えます。カード上のチップ自体が独立したマイクロプロセッサとなっているため、カードリーダーに挿入するか、近距離無線通信（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標準として定義されており、Web開発者が期待する動作や管理がしやすい設計となっています。さらに、認証と認可が密接に連携しており、RESTプロトコルやJSONベースの情報標準などのアクセス手法を活用することで、フル機能かつ拡張可能な仕組みを実現しています。Web SSOシステムは、複数のドメインや大規模な環境でも円滑に機能するよう設計されています。

  • LDAP： Lightweight Directory Access Protocol（LDAP）は、1990年代に導入されたプロトコルで、ユーザーがローカルネットワーク上で利用したいサーバーやプリンターなどのリソースを検索・利用できるようにするために開発されました。LDAPは、ドメイン内のすべてのリソース情報を把握している認証サーバーの存在を前提としており、そのためインターネット用途には適していません。

    LDAPはネットワークリソースへのアクセス権を付与する役割を持っているため、LDAPサーバー上に保存されたユーザー認証情報を用いたユーザー認証システムも備えています。ただし、その認証メカニズムは強固とは言えず、例えばパスワードがネットワーク上に平文で送信されることもあります。暗号化を必要とする場合は、SSL/TLSなどの別のプロトコルによる保護が必要です。

    LDAPの大きな利点は、柔軟かつ拡張性が高い点です。これにより企業は、従業員の組織内での役割やグループメンバーシップ、オフィス所在地や電話番号といった属性情報など、さまざまな情報をLDAPに保存し、管理できます。一方で、より細かなアクセス権限管理、たとえば特定のデータに誰がアクセスできるかといった権限管理についてはLDAP単体で柔軟に管理することが難しい場合があります。

  • JWT： JSON Web Token（JWT）は、情報を構造化された形で安全に当事者間で送信するためのコンパクトなドキュメントです。SAMLのドキュメントと同じ用途を満たしますが、より簡潔な形式のため、URL内に含める用途にも適しています。JWTは公開鍵暗号技術を使って署名されており、その正当性が保証されます。Open Authentication（OAuth）では、ユーザー認証後、IDサーバーからJSON形式のIDトークンが返されます。

    保護されたリソースへのアクセスを認可するリクエストを行うと、その後JSON形式のアクセストークンが返されます。このアクセストークンは、その後リソースサーバーに対して行うすべてのリクエストに必ず含める必要があります。これにより、ユーザーが認証・認可済みであるという状態がすべてのリクエストに含まれ、「RESTful」なやりとりとなります。REST（Representational State Transfer）は、リソースサーバーが、そのリソースを利用しようとするすべてのクライアントとセッションを確立・維持する必要がないという利点があります。

    JWTは平文ドキュメントであるため、HTTPSで暗号化された通信経路上で使用することが推奨されます。一般に、トークンには個人を特定できる情報などの機密情報は含まれないよう設計されています。また、トークンは国際標準であるX.509（公開鍵証明書のフォーマット規格）に準拠して署名されており、リソースサーバーは署名を検証してトークンが改ざんされていないことを確認します。JWTはOAuthやOpenIDベースの認証・認可システムの構成要素として利用されており、Webアプリケーション向けに設計されているため大規模運用や複数ドメインをまたぐ用途にも適しています。

SSOのメリット

ITやセキュリティの専門家は、SSOを高く評価する傾向があります。その理由は、ユーザー認証を中央集約化し、機微な情報を保護しながら、エンタープライズシステムやアプリケーションとの統合管理を実現できるためです。専門家たちは必要なユーザー研修や継続的な運用・監視にも前向きに取り組む傾向があります。これは、SSO技術がもたらす数多くの大きなメリットによるものです。

  • アクセス管理の一元化： SSOシステムは、多くの企業やクラウド事業者が管理する複数のアプリケーションのユーザーアカウントやアクセス権の管理負担を大きく軽減します。すべてのアプリケーションへのアクセス権は、1か所で一元的に付与・解除できます。たとえば、従業員が退職した場合でも、個別アプリケーションごとに認証情報を削除する必要がありません。セキュリティ担当者は、認証システムに関する変更も一カ所で行えるため、個々のアプリケーションを個別に修正する必要がなくなります。
  • セキュリティの向上： SSOの導入により、従業員が記憶しなければならないユーザー名とパスワードの組み合わせが大幅に削減されます。負担が減ることで、特に企業環境においては、多要素認証や強固なパスワードポリシーの導入など、認証交換のセキュリティを高める取り組みがしやすくなります。
  • 従業員の生産性向上： SSOの導入によって、従業員がユーザー名やパスワードを覚える手間が大幅に軽減されます。一度認証が完了すれば、多くのアプリケーションに再認証なしでアクセスできるため、本来の業務に迅速に取りかかることができます。導入方法によっては、引き続き個別のアプリケーションで認証が求められる場合もありますが、少なくともSSOの認証情報だけを覚えていれば問題ありません。
  • パスワード疲弊の軽減： 実際のところ、誰もが何十ものユーザー名やパスワードの組み合わせに対応したくはありません。複雑なパスワードを覚えることが難しい上に、頻繁に変更しなければならない場合はなおさらです。その結果、簡単に推測できるパスワードを使ったり、複数のアカウントで同じパスワードを使い回したり、パスワードをポストイットに書いて管理するなど、不適切な方法に頼ってしまいがちです。SSOはこうした負担を大きく軽減します。
  • 規制コンプライアンス： SSOは、上記で触れた中央集約型アクセス管理のメリットにより、各種規制やコンプライアンスへの対応を容易にします。監査や問題発生時の是正対応も、チェックすべきフレームワークが1つに集約されているため、シンプルに行えます。
  • シンプルな統合 典型的な企業では、膨大な量のデータを複数のデータベースインスタンスで管理しています。たとえば、製造部門用、サプライチェーン用、財務や営業、マーケティング用など、それぞれ個別のデータベースを持っている場合もあります。営業担当が在庫データにアクセスできると非常に便利ですが、CRMシステムがそのデータにアクセスする際、本来は営業担当者がCRMだけでなく在庫管理データベースにも認証されている必要があります。SSOを使えば、リクエスターの認証済みIDを提供でき、アクセス・トークンを活用することで、役割ごとに閲覧可能なデータの範囲も制御できます。SSOがなければ、CRMと在庫システム間の連携ははるかに困難となり、ユーザーには追加の認証ステップが発生したり、在庫データのセキュリティが低下するリスクも生じます。
  • 効率的なユーザー・エクスペリエンス エンタープライズ・アプリケーションやWebアプリケーションへの認証回数を減らすことでユーザー・エクスペリエンスが向上します。多くの人々は個人のオンライン体験でSSOの利用に慣れているため、特別なトレーニングも不要です。

SSOとセキュリティ：SSOは安全なのか？

まず、「完全に安全」というものは存在せず、セキュリティには段階があることを前提にする必要があります。それでも市販のSSO基盤は極めて高いセキュリティを実現しており、これこそがSSO技術の重要なポイントでもあります。一般的に、SSOシステム単体でセキュリティを完結できるわけではありませんが、セキュアな環境を構築するうえで極めて重要な要素となります。ユーザー認証を行い、アプリケーションや他のリソース提供システムに認証情報を供給する役割は、全体的なセキュリティ戦略の中核を担っています。

SSOとプライバシー

SSOはプライバシー向上にも寄与しますが、その内容は実装ごとに異なります。たとえば、SAMLやJWTが返すレスポンスには、最低限として認証証明が含まれています。また、ユーザーが所属するグループやロールなど、実装者が必要に応じて提供する追加情報が含まれることもあります。

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

エンタープライズにおいては、SSOシステムは認証証明とともに、ユーザーのロールに関する情報も返すのが理想的です。また、ユーザーの勤務するオフィス所在地や業務用電話番号などを提供することが有用な場合もあります。しかし、それ以外の情報の提供は制限されるべきです。デフォルトで提供される情報は通常、人事部門の方針によって定められます。

SSOのユースケース

SSOは、1つのログイン認証情報だけで多数のアプリケーションやシステムにシームレスにアクセスできるよう設計されています。厳格な規制遵守が求められる組織では、追加のセキュリティ対策が必要となる場合がありますが、SSOの活用シーンは数多く存在します。主な事項は以下の通りです。

  • エンタープライズ・アプリケーション 多くの企業では、数十から数百のアプリケーションを管理しており、それぞれでユーザーの認証が必要となります。アプリケーションごとに個別のID管理システムを構築・運用するのは、利用者にもIT部門にも現実的とは言えません。SSOを導入することで、従業員は一度だけ認証を行い、その認証をもとに必要なリソースへの利用権限管理を行うことが可能となります。

    認証証明は通常、一定期間、かつ単一システム内でのみ有効です。より詳細な従業員の役割情報はSSOシステム内で保持され、アプリケーションや認可システムが必要に応じて活用し、アプリケーションやデータ、その他のリソースへの限定的なアクセスを提供します。

  • クラウドベースのアプリケーション： ビジネス用途でも個人用途でも、クラウドベースのシステムにはエンタープライズ向けSSOシステムとは異なる認証・認可の要件があります。消費者向けの場合、利便性が重視され、一度認証すれば同じデバイスから継続してサービスを利用できることが一般的です。たとえばGmailに一度ログインすれば、再認証することなくDocsやSheetsなど他のGoogleアプリケーションも利用可能になります。ビジネス向けでは、SaaSアプリケーションやプラットフォーム、インフラサービスを提供するクラウド事業者も、ユーザーの身元確認後は、そのユーザーの役割や契約範囲に応じて幅広いサービスへのアクセスを許可します。認証は、より大規模なサービス認可スキームの第一歩であり、一度のログインで多彩なサービス利用が可能となります。各アプリケーションごとに、ユーザーがどの役割（たとえば、あるアプリでは管理者、別のアプリでは開発者、さらに別のアプリでは一般ユーザーなど）を持つかによって、サービスの利用範囲が決まります。

SSOの実装

社内に十分なセキュリティ専門知識がなくても、SSO導入を諦める必要はありません。マネージドサービス事業者やSSOベンダーの実装チームが支援してくれます。多くの企業は、サードパーティ事業者が提供するSSOサービスを利用しています。これにより、専門知識や高度なセキュリティ機能、拡張性の恩恵を受けることができ、IT部門はSSO運用の専門家に任せつつ、自社のビジネス成長支援に集中することが可能となります。

全体的な導入プロセスには、次の3つの主要要素があります。

  1. クライアント認証システムの選定と展開：エンドユーザーからユーザー名やパスワードなどの入力を安全に収集できる認証システムを選び、配布します。多くの場合、これらはWebページとして提供されるため、デバイスを問わず認証プロセスを統一しやすいのがメリットです。エンタープライズの場合、ユーザーは通常、社内ネットワークへの接続またはVPN経由のアクセスが必要となります。これにより、組織は一元的で信頼性の高いID管理システムを構築できます。
  2. IDマネージャの設定：ユーザー認証を実施し、組織に代わって証明書を発行するIDマネージャを構築します。多くの場合、IDマネージャはユーザーのアプリ内操作権限を示す認可トークンも発行するシステムの一部であるか、または認可サーバーと密接に連携しています。
  3. アプリケーションの設定または修正：各アプリケーションが独自のユーザーIDシステムを保持するのではなく、SSOや認可システムから発行される証明書やトークンを利用できるように設定または修正を行います。

SSOのベストプラクティス

サードパーティの支援を受けてSSOを社内に導入する場合でも、サービスとして利用する場合でも、成功のための重要なポイントがあります。主な事項は以下の通りです。

  1. 多要素認証（MFA）の必須化： SSOにより、組織はパスワードポリシーを一元的に強化できるだけでなく、より高度な認証技術である多要素認証も導入可能となります。多要素認証には、スマートカード、スマートフォンアプリケーション、さまざまな生体認証などが含まれます。
  2. ロールベースアクセス制御（RBAC）の活用： ユーザーを認証するだけでは、エンタープライズリソースへのアクセス管理全体の課題を解決することはできません。次の課題は、各ユーザーが許可されたリソースのみにアクセスできるよう制限することです。マーケティング、財務、製造、営業などのグループや、各グループ内の役割を明確にすることで、きめ細かいアクセス制御を実現し、管理も一元化しやすくなります。
  3. 監査や新たな標準への対応： 認証を1つのフレームワークに集約することで、監査や新たな標準への迅速な対応が容易になります。
  4. ロール・権限管理の実装： SSOはゼロトラストの考え方にも通じるものがあります。ユーザーは自身の役割に明示的に必要なリソースだけにアクセスでき、明示的に許可されたデータだけが表示可能となります。
  5. データプライバシー法の遵守： SSOフレームワークを利用することで、データプライバシー法への準拠が保証されるわけではありませんが、法令遵守の実現と証明がはるかに容易になります。

オラクルによるセキュアかつ簡単なアクセス制御

Oracle Cloud Infrastructure（OCI）や、クラウドおよびオンプレミスの各種アプリケーションに対するユーザーIDおよびアクセス管理が必要ですか？Oracle Cloud Infrastructure Identity and Access Management (IAM) は、ゼロトラストセキュリティ戦略を採用する組織向けに、必要な管理・統合ツールを提供します。

多要素認証（MFA）対応のユニバーサル認証基盤の導入をお考えですか？Oracle Access Managementは、オンプレミスとクラウドの両方に対し、柔軟な認証管理システムを提供します。デバイスや場所を問わず、ユーザーにポリシーを紐づけることが可能です。これにより、あらゆる場所・タイミング・デバイスからのデータアクセスを安全に実現できます。MFAのほか、オラクルのIAMソリューションでは、信頼できるデバイスのSSOやアプリケーションのSSOにも対応しており、ゼロトラストアーキテクチャの実現に不可欠な機能を網羅しています。

ビジネスで利用するアプリケーションやサービス、データソースが増える中で、ユーザーの認証と認可管理はますます複雑化しています。SSOフレームワークを利用することで、エンドユーザーとアプリケーション設計者双方の負担を軽減し、認証・認可プロセスを簡素化できます。

AIは、生体認証、不正検知、プロビジョニングなどの機能を通じて、SSOシステムの能力やセキュリティを大幅に強化することができます。AIの導入を安全かつコスト効率良く開始する方法についてご紹介します。

SSOに関するよくある質問

SSOとは何の略ですか？

SSOはSingle Sign-On（シングルサインオン）の略です。

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

SSOアカウントとは、1組のログイン情報だけで複数のアプリケーションやシステムにアクセスできる、統合認証サービスのことです。つまり、組織が提供するすべてのサービスやリソースにアクセスする際に、1つのユーザー名とパスワードだけを覚えていれば済みます。SSOアカウントを使うことで、ログインプロセスが簡素化され、セキュリティが向上し、必要な情報やツールにより簡単にアクセスできるようになります。

SSOの例にはどのようなものがありますか？

消費者向けでは、Amazon、Google、Meta、Microsoftなどの大手ベンダーが、他のアプリケーションで使用するユーザー認証情報の提供元となっています。たとえば、認証情報を入力する代わりに、これらのサービスのいずれかを使ってログインするダイアログボックスが表示された場合、それがSSOです。