第1章 一般的なセキュリティー概念の概要
JBoss EAP がどのようにセキュリティーに対処するかを深く掘り下げる前に、基本のセキュリティー概念を理解することが重要です。
1.1. 認証
認証とは、認証の対象を特定し、その識別情報の真正性を検証することを言います。ユーザー名とパスワードの組み合わせが最も一般的な認証メカニズムですが、共有キー、スマートカード、指紋なども認証に使用されます。Java Enterprise Edition の宣言的セキュリティーでは、正常な認証の結果はプリンシパルと呼ばれます。
1.2. 承認
承認は、アクセス権を指定したり、アクセスポリシーを定義したりする方法のことです。システムはメカニズムを実装してこれらのポリシーを使用し、要求側のリソースへのアクセスを許可または拒否できます。多くの場合で、ロールと呼ばれる要求側のアクセスが許可されるアクションまたは場所のセットと、プリンシパルが一致すると実装されます。
1.3. 実際の認証および承認
認証と承認は異なる概念ですが、多くの場合で関係しています。認証の処理が目的で作成された多くのモジュールは承認も処理し、承認の処理が目的で作成された多くのモジュールは認証も処理します。
例
アプリケーション MyPersonalSoapbox はメッセージを投稿および閲覧する機能を提供します。Talk ロールを持つプリンシパルはメッセージを投稿でき、投稿された他のメッセージを閲覧できます。ログインしていないユーザーは Listen ロールを持ち、投稿されたメッセージを閲覧できます。Suzy、Adam、および Bob がアプリケーションを使用します。Suzy とBob はユーザー名とパスワードで認証できますが、Adam のユーザー名とパスワードはまだ指定されていません。Suzy は Talk ロールを持ちますが、Bob は何のロールも持たず、Talk や Listen も持っていません。Suzy が認証されると、Suzy はメッセージを投稿し、閲覧することができます。Adam が MyPersonalSoapbox を使用すると、ログインはできませんが、投稿されたメッセージを閲覧できます。Bob はログインしてもメッセージを投稿できず、投稿された他のメッセージも見れません。
Suzy に対しては認証と承認の両方が行われます。Adam は認証されませんが、Listen ロールで承認され、メッセージを閲覧できます。Bob は認証されますが、承認されず、ロールを持ちません。
1.4. 暗号化
暗号化とは、数学的なアルゴリズムを適用して機密情報をエンコードすることを言います。データは、エンコードされた形式に変換 (暗号化) され、セキュア化されます。データを再度読み取るには、エンコードされた形式を元の形式に変換 (復号化) する必要があります。暗号化は、ファイルやデータベースの簡単な文字列データに適用でき、通信ストリーム全体に送信されたデータでも適用できます。
暗号化の例には以下の場合が含まれます。
- LUKS を使用して Linux ファイルシステムディスクを暗号化できます。
- blowfish または AES アルゴリズムを使用して Postgres データベースに格納されたデータを暗号化できます。
- HTTPS プロトコルは、SSL/TLS (Secure Sockets Layer/Transport Layer Security) 経由ですべてのデータを暗号化してから転送元から転送先へ送信します。
- ユーザーが SSH プロトコル (Secure Shell) を使用してあるサーバーから別のサーバーに接続する場合、すべての通信は暗号化されたトンネルで送信されます。
1.5. SSL/TLS および証明書
SSL/TLS は、2 つのシステム間でのみ交換および認識される対称キーを使用して、このシステム間のネットワークトラフィックを暗号化します。SSL/TLS は対称キーをセキュアに交換するため、暗号化でキーペアを使う PKI (Public Key Infrastructure) を使用します。キーペアは、個別のキーでありながら一致する、パブリックキーとプライベートキーの 2 つの暗号キーで構成されます。パブリックキーは第三者と共有でき、データの暗号化に使用されます。プライベートキーは秘密のキーとして扱われ、パブリックキーを使用して暗号化されたデータの復号化に使用されます。
クライアントが対称キーを交換するためにセキュアな接続を要求すると、セキュアな通信の開始前にハンドシェイクフェーズが発生します。SSL/TLS ハンドシェイクの間、サーバーはパブリックキーを証明書としてクライアントに渡します。証明書には、サーバーの識別情報、その URL、サーバーのパブリックキー、および証明書を検証するデジタル署名が含まれます。クライアントは証明書を検証し、信頼できる証明書であるかを判断します。証明書を信頼できる場合、クライアントは SSL/TLS 接続の対称キーを生成し、サーバーのパブリックキーを使用して暗号化し、サーバーに返送します。サーバーはプライベートキーを使用して対称キーを復号化します。その後、この接続上の 2 つのマシン間で行われる通信は対称キーを使用して暗号化されます。
証明書には、自己署名証明書と認証局署名証明書の 2 つの証明書があります。自己署名証明書はプライベートキーを使用してその証明書自体を署名します。信頼チェーンに接続されていないため、署名は検証されません。認証局署名証明書は認証局 (CA) によって発行される証明書で、VeriSign、CAcert、RSACA などの CA によって署名されます。CA は証明書の保持者の信頼性を検証します。
自己署名証明書の生成は迅速かつ簡単で、管理に必要なインフラストラクチャーが少なくなりますが、第三者によって信頼性が確認されないため、クライアントによる信頼性の検証が難しくなる可能性があります。そのため、自己署名証明書の安全性は低くなります。認証局署名証明書の設定はより手間がかかりますが、クライアントによる信頼性の検証が容易になります。第三者によって証明書の信頼性が確認されるため、信頼チェーンが作成されます。
Red Hat では、影響するすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSLv2、SSLv3、および TLSv1.0 を明示的に無効化することを推奨しています。
1.6. シングルサインオン
シングルサインオン (SSO) は、1 つのリソースに対して認証されたプリンシパルが暗黙的に他のリソースへのアクセスを承認できるようにします。異なるリソースのセットが SSO によってセキュア化された場合、ユーザーはセキュア化されたこれらのリソースのいずれかに初めてアクセスするときのみ認証される必要があります。認証に成功した後、ユーザーに関連するロールが保存され、関連する他のリソースすべての承認に使用されます。これにより、ユーザーは再認証なしで、承認された他のリソースにアクセスできます。
ユーザーがリソースからログアウトした場合や、リソースがプログラムでセッションを無効化した場合、永続化された承認データはすべて削除され、プロセスが再度開始されます。リソースのセッションタイムアウトが発生した場合は、そのユーザーに関連する有効なリソースセッションが他にあれば SSO セッションは無効化されません。SSO は、web アプリケーションやデスクトップアプリケーションでの認証および承認に使用することができます。場合によっては、SSO 実装は認証と承認の両方と統合できます。
SSO 内では、システムの異なる概念や部分を示すために共通の用語がいくつか使用されます。
アイデンティティー管理
アイデンティティー管理 (IDM) とは、1 つ以上のシステムやドメイン全体でプリンシパルとそれらに関連する認証、承認、および特権を管理する概念のことです。同じ概念がアイデンティティーおよびアクセス管理 (IAM) と呼ばれることもあります。
アイデンティティープロバイダー
アイデンティティープロバイダー (IDP) とはエンドユーザーを認証し、そのユーザーのアイデンティティーを信頼できる方法で信頼できるパートナーに対してアサートする、権限のあるエンティティーです。
アイデンティティーストア
アイデンティティープロバイダーには、認証および承認プロセス中に、使用するユーザーの情報を取得するアイデンティティーストアが必要です。データベース、LDAP (Lightweight Directory Access Protocol)、プロパティーファイルなど、あらゆるリポジトリーのタイプをアイデンティティーストアとして使用できます。
サービスプロバイダー
サービスプロバイダー (SP) は、アイデンティティープロバイダーに依存してユーザーの電子クレデンシャル経由でユーザーに関する情報をアサートし、信頼できるユーザークレデンシャルのアサートを基にアクセス制御と伝播を管理します。
クラスター化および非クラスター化 SSO
非クラスターか SSO は、同じ仮想ホストでアプリケーションへの承認情報の共有を制限します。また、ホストの障害発生時の回復性がありません。クラスター化された SSO の場合、複数の仮想ホストのアプリケーション間でデータが共有されるため、障害時の回復性があります。さらに、クラスター化された SSO はロードバランサーからリクエストを受信できます。
1.6.1. サードバーティー SSO 実装
Kerberos
Kerberos はクライアントサーバーアプリケーションのネットワーク認証プロトコルです。秘密鍵暗号方式を使用して、セキュアでないネットワーク上でセキュアな認証を実現します。
Kerberos はチケットと呼ばれるセキュリティートークンを使用します。セキュアなサービスを使用するには、ユーザーはネットワークのサーバーで実行されるサービスであるチケット付与サービス (TGS: Ticket Granting Service) からチケットを取得する必要があります。チケットの取得後、同じネットワークで実行される別のサービスである認証サービス (AS) からサービスチケット (ST) を要求します。その後、ユーザーは ST を使用して希望のサービスに対して認証されます。TGS と AS は、キー配布センター (KDC) と呼ばれるエンクロージングサービス内で実行されます。
Kerberos は、クライアントサーバーデスクトップ環境での使用を目的としているため、通常は web アプリケーションやシンクライアント環境では使用されません。しかし、 デスクトップの認証に Kerberos システムを使用しているため、web アプリケーション用のシステムを作成せずに、既存のシステムを再使用したい組織が多くあります。Kerberos はMicrosoft Active Directory では不可欠なもので、Red Hat Enterprise Linux 環境の多くで使用されています。
SPNEGO
SPNEGO (Simple and protected GSS_API negotiation mechanism) は、web アプリケーションで使用するために Kerberos ベースの SSO 環境を拡張するメカニズムを提供します。
web ブラウザーなどのクライアントコンピューター上のアプリケーションが web サーバーの保護されたページにアクセスしようとすると、サーバーは承認が必要であることを伝えます。アプリケーションは KDC から ST を要求します。アプリケーションはチケットを SPNEGO 用にフォーマットされたリクエストにラップし、ブラウザー経由で web アプリケーションに返信します。デプロイされた web アプリケーションを実行している web コンテナーはリクエストをアンパックし、チケットを認証します。認証が正常に行われると、アクセスできるようになります。
SPNEGO は、Red Hat Enterprise Linux 内の Kerberos サービスや、Microsoft Active Directory の不可欠な要素である Kerberos サーバーなど、すべてのタイプの Kerberos プロバイダーと動作します。
Microsoft Active Directory
Active Directory (AD) は Microsoft 社によって開発されたディレクトリーサービスで、Microsoft Windows ドメインでユーザーとコンピューターを認証します。これは Windows Server の一部として提供されます。ドメインを制御する Windows Server を実行しているコンピューターはドメインコントローラーと呼ばれます。Red Hat Enterprise Linux は Active Directory ドメインと統合でき、Red Hat Identity Management、Red Hat JBoss Enterprise Application Platform、およびその他の Red Hat 製品とも統合できます。
Active Directory は、共に動作する 3 つのコアテクノロジーに依存します。
- LDAP: ユーザー、コンピューター、パスワード、およびその他のリソースに関する情報を保存します。
- Kerberos: ネットワーク上でセキュアな認証を提供します。
- ドメインネームサービス (DNS): ネットワーク上のコンピューターおよびその他のデバイスにおける IP アドレスとホスト名との間のマッピングを提供します。
1.6.2. クレームベースのアイデンティティー
SSO を実装する方法の 1 つがクレームベースのアイデンティティーシステムを使用することです。クレームベースのアイデンティティーシステムでは、システムはアイデンティティー情報を渡すことができますが、その情報をクレームと発行者 (またはオーソリティー) の 2 つに抽象化します。クレームは、ユーザー、グループ、アプリケーション、組織などの 1 つのサブジェクトが他のサブジェクトに関して作成するステートメントです。1 つまたは複数のクレームは、1 つまたは複数のトークンにパッケージ化され、プロバイダーによって発行されます。クレームベースのアイデンティティーでは、個別のセキュアなリソースがユーザーに関する情報をすべて認識しなくても SSO を実装できます。
セキュリティートークンサービス
セキュリティートークンサービス (STS) は、セキュアなアプリケーション、web サービス、または EJB に対してユーザーを認証および承認するときに使用するセキュリティートークンをクライアントに発行する認証サービスです。STS でセキュア化されたアプリケーションに対して認証を試みるクライアント (サービスプロバイダー) は集中管理された STS オーセンティケーターにリダイレクトされ、トークンが発行されます。認証に成功すると、そのクライアントはトークンと元のリクエストを提供してサービスプロバイダーへ再度接続しようとします。そのサービスプロバイダーはクライアントのトークンを STS で検証し、処理を継続します。クライアントは STS に接続する他の web サービスや EJB に対して同じトークンを再使用できます。セキュリティートークンを発行、キャンセル、更新、および検証でき、セキュリティートークンのリクエストおよび応答メッセージの形式を指定する集中管理された STS の概念は、WS-Trust と呼ばれます。
ブラウザーベースの SSO
ブラウザーベースの SSO では、サービスプロバイダーと呼ばれる 1 つ以上の web アプリケーションがハブアンドスポーク型アーキテクチャーの集中管理されたアイデンティティープロバイダーに接続します。IDP は、SAML トークンのクレームステートメントをサービスプロバイダー (スポーク) に発行し、アイデンティティーおよびロール情報の中心のソース (ハブ) として動作します。リクエストは、ユーザーがサービスプロバイダーへのアクセスを試みるときや、ユーザーが直接アイデンティティープロバイダーでの認証を試みるときに発行されます。これらはそれぞれ SP 開始 (SP-initiated) フローおよび IDP 開始 (IDP-initiated) フローと呼ばれ、どちらも同じクレームステートメントが発行されます。
SAML
SAML (Security Assertion Markup Language) は、通常はアイデンティティープロバイダーとサービスプロバイダーである 2 者が認証および承認情報を交換できるようにするデータ形式です。SAML トークンは、STS または IDP によって発行されるトークンの種類で、SSO の有効化に使用できます。SAML によってセキュア化されるリソースである SAML サービスプロバイダーは、STS または IDP の種類の 1 つである SAML アイデンティティープロバイダーにユーザーをリダイレクトし、そのユーザーを認証および承認する前に有効な SAML トークンを取得します。
デスクトップベースの SSO
デスクトップベースの SSO は、サービスプロバイダーとデスクトップドメイン (Active Directory または Kerberos など) がプリンシパルを共有できるようにします。これにより、ユーザーはドメインクレデンシャルを使用してコンピューターにログインでき、サービスプロバイダーは認証中にそのプリンシパルを再使用できるため、再認証や SSO の提供が必要ありません。
1.7. LDAP
LDAP (Lightweight Directory Access Protocol) はネットワーク全体でディレクトリー情報を格納および分散するプロトコルです。このディレクトリー情報には、ユーザー、ハードウェアデバイス、アクセスロール、制限に関する情報などが含まれます。
LDAP では、識別名 (DN) によってディレクトリーのオブジェクトが一意に識別されます。各識別名には、他のオブジェクトと区別するための一意名と場所が必要で、これには属性と値のペア (AVP) を使用します。AVP は、コモンネームや組織単位などの情報を定義します。LDAP に必要となる一意な文字列は、これらの値の組み合わせになります。
LDAP の一般的な実装には、Red Hat Directory Server、OpenLDAP, Active Directory、IBM Tivoli Directory Server、Oracle Internet Directory、および 389 Directory Server が含まれます。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.