java.security.Providerクラスは、セキュリティ・プロバイダの概念をJavaプラットフォームでカプセル化します。プロバイダの名前を指定し、実装するセキュリティ・サービスを一覧します。複数のプロバイダが同時に構成される場合があり、それらは優先順にリストされます。セキュリティ・サービスが要求されると、そのサービスを実装する、優先順位がいちばん高いプロバイダが選択されます。

アプリケーションは、関連するgetInstanceメソッドによって、基盤となるプロバイダからセキュリティ・サービスを要求します。

たとえば、メッセージ・ダイジェストの作成は、プロバイダから利用可能なサービスの1つのタイプを表します。特定のメッセージ・ダイジェスト・アルゴリズムの実装を要求するには、メソッドjava.security.MessageDigest.getInstanceを呼び出します。次の文は、プロバイダ名を指定せずにSHA-256メッセージ・ダイジェスト実装を要求します。

    MessageDigest md = MessageDigest.getInstance("SHA-256");

次の図では、この文でSHA-256メッセージ・ダイジェスト実装がどのように取得されるかを示します。プロバイダが優先順位に従って検索され、その特定のアルゴリズムを提供する最初のプロバイダであるProviderBからの実装が返されます。

図1-1 プロバイダ指定なしでのSHA-256メッセージ・ダイジェスト実装の要求

「図1-1 プロバイダ指定なしでのSHA-256メッセージ・ダイジェスト実装の要求」の説明

オプションで、プロバイダ名を指定することで特定のプロバイダからの実装を要求できます。次の文は、特定のプロバイダProviderCからのSHA-256メッセージ・ダイジェスト実装を要求します。

    MessageDigest md = MessageDigest.getInstance("SHA-256", "ProviderC");

次の図では、この文で特定のプロバイダProviderCからのSHA-256メッセージ・ダイジェスト実装がどのように要求されるかを示します。この場合は、優先順位の高いプロバイダであるProviderBもSHA-256実装を提供していても、指定されたプロバイダからの実装が返されます。

図1-2 特定のプロバイダからのSHA-256メッセージ・ダイジェスト実装の要求

「図1-2 特定のプロバイダからのSHA-256メッセージ・ダイジェスト実装の要求」の説明

メッセージ・ダイジェスト・アルゴリズムなどの暗号化サービスの詳細は、Javaの暗号化の項を参照してください。

OracleのJavaプラットフォーム実装には、アプリケーションによって使用できる一連の基本的なセキュリティ・サービスを実装する、組込みの多数のデフォルト・プロバイダが含まれています。Javaプラットフォームのほかのベンダーの実装には、ベンダー固有のセキュリティ・サービスのセットをカプセル化した、異なるプロバイダのセットが含まれている場合があります。組込みのデフォルト・プロバイダという用語は、Oracleの実装で利用可能なプロバイダのことを指しています。

次の表では、Javaセキュリティのクラスおよびインタフェースの名前、パッケージおよび使用方法をいくつか示します。

Javaプラットフォームは、キーストアおよび証明書ストアを使用して、暗号化キーおよび証明書の長期にわたる永続的なストレージを提供します。具体的には、java.security.KeyStoreクラスがキーストアを表し、java.security.cert.CertStoreクラスが証明書ストアを表します。キーストアは、(たとえば、証明書パス検証中に使用される)暗号化キーまたは信頼できる証明書、あるいはその両方のセキュアなリポジトリです。証明書ストアは、関連がなく通常は信頼されない証明書が含まれるため非常に大きくなる可能性がある公開リポジトリです。CertStoreはCRLを格納する場合もあります。

KeyStoreとCertStoreの実装は、タイプによって区別されます。Javaプラットフォームには、標準のPKCS11とPKCS12キーストア・タイプ(その実装は、RSA Securityの対応するPKCS仕様に準拠する)が含まれています。さらに、JKS (Java Key Storeを表す)と呼ばれる独自のファイルベースのキーストア・タイプと、DKS (Domain Key Store)と呼ばれるタイプも含まれます。DKSは単一の論理キーストアとして存在するキーストアのコレクションです。

Javaプラットフォームには、特別な組込みキーストアcacertsが含まれています。このキーストアには、既知の信頼できるCAの多数の証明書が含まれています。keytoolユーティリティでは、cacertsに含まれている証明書をリストできます。Java Development Kitツール仕様のkeytoolに関する項を参照してください。

Javaの暗号化の項で説明されているSunPKCS11プロバイダには、PKCS11 KeyStore実装が含まれています。つまり、安全なハードウェア(スマートカードなど)に存在するキーや証明書は、KeyStore APIによってJavaアプリケーションからアクセスおよび使用できます。スマートカードのキーがデバイスを離れることは許可されない場合があります。このような場合、KeyStore APIから返されるjava.security.Keyオブジェクトは、単純にキーの参照になる(つまり、実際のキー・データは含まれない)ことがあります。このようなKeyオブジェクトは、実際のキーが存在するデバイスでの暗号化操作の実行にのみ使用できます。

Javaプラットフォームには、LDAP証明書ストア・タイプ(LDAPディレクトリに格納されている証明書へのアクセス用)、およびメモリー内のCollection証明書ストア・タイプ(java.util.Collectionオブジェクトで管理されている証明書へのアクセス用)も含まれています。

キー、証明書、およびキー・ストアを操作するための2つの組込みツールがあります。

• keytoolでは、キーストアを作成および管理します。これは、次のタスクを実行するために使用します。

  • 公開キーと秘密キーのペアを作成する
  • ファイルとして格納されたX.509 v1、v2、およびv3証明書を表示、インポート、エクスポートする
  • X.509証明書の作成
  • CAに送信される証明書(PKCS#10)要求を発行する
  • 証明書要求に基づいて証明書を作成する
  • 証明書応答をインポートする(証明書要求の送信先のCAから取得する)
  • 公開キー証明書を信頼できるものとして指定する
  • パスワードを受け付け、それを秘密キーとしてセキュアに保存する

• jarsignerは、JARファイルに署名し、署名付きJARファイルの署名を検証します。Java ARchive (JAR)ファイル形式を使用すると、複数のファイルを1つのファイルに統合できます。JARファイルには、主にアプレットおよびアプリケーションに関連したクラス・ファイルおよび補助リソースが含まれています。

Java Development Kitツール仕様のkeytoolおよびjarsignerに関する項を参照してください。

Transport Layer Security (TLS)とその前身であるSecure Sockets Layer (SSL)は、2つの通信ピア間のセキュアなチャネルを実現する暗号プロトコルです。TLSでは、信頼されないまたは潜在的に攻撃的なネットワーク経由の通信に対して、認証、機密性および整合性のプロパティを提供することで、複数の暗号化プロセスを組み合せて使用します。TLSは、信頼できるストリーム指向のトランスポート・チャネル(通常はTransport Control Protocol (TCP))を介して実行されます。TLSはアプリケーション・プロトコルに依存しません。Hypertext Transfer Protocol (HTTP)などの高レベル・プロトコルは、TLS上に透過的にレイヤー化できます。

Datagram Transport Layer Security (DTLS)プロトコルは、ストリーム指向のTLSプロトコルを基盤とし、信頼できる順次のデータ配信を提供しないデータグラム・トランスポート(User Datagram Protocol (UDP)など)に対して同様のセキュリティ・プロパティを提供することを目的としています。

JDKは、SSL、TLSおよびDTLSプロトコルのAPIおよび実装を提供しています。これには、データの暗号化、メッセージの整合性、およびサーバーとクライアントの認証の機能が含まれています。アプリケーションは、(D)TLSを使用して、TCP/IP上のHTTPなど、任意のアプリケーション・プロトコル上の2つのピア間でセキュアなデータのやり取りを実現できます。

javax.net.ssl.SSLSocketクラスは、通常のストリーム・ソケット(java.net.Socket)上でTLSサポートをカプセル化するネットワーク・ソケットを表します。一部のアプリケーションは、別のデータ・トランスポート抽象化(New-I/Oなど)を使用する場合があります。javax.net.ssl.SSLEngineクラスを使用して、TLS/DTLSパケットを生成および消費できます。

JDKには、プラガブルな(プロバイダ・ベースの)キー・マネージャおよびトラスト・マネージャの概念をサポートするAPIも含まれています。キー・マネージャはjavax.net.ssl.KeyManagerクラスによってカプセル化され、認証の実行に使用されるキーを管理します。トラスト・マネージャはTrustManagerクラス(同じパッケージ内)によってカプセル化され、管理するキーストア内の証明書に基づいて信頼できる人を決定します。

JDKには、次のSSL/TLS/DTLSプロトコルを実装する組込みプロバイダが含まれています。

• SSL 3.0
• TLS 1.0
• TLS 1.1
• TLS 1.2
• TLS 1.3
• DTLS 1.0
• DTLS 1.2

Simple Authentication and Security Layer (SASL)は、認証およびオプションでクライアント・アプリケーションとサーバー・アプリケーション間のセキュリティ層の確立を行うプロトコルを指定するインターネット標準です。SASLは、認証データの交換方法を定義しますが、そのデータの内容は指定しません。認証データの内容およびセマンティックスを指定する特定の認証メカニズムが適合できるフレームワークです。さまざまなセキュリティ・レベルおよび配備シナリオ用にインターネット・コミュニティによって定義された、多数の標準SASLメカニズムがあります。

Java SASL APIは、java.security.saslモジュール内にあり、SASLメカニズムを使用するアプリケーション用のクラスおよびインタフェースを定義します。これは、メカニズムに依存しないように定義されています。APIを使用するアプリケーションを、特定のSASLメカニズムの使用に固定する必要はありません。アプリケーションは、必要なセキュリティ機能に基づいて、使用するメカニズムを選択できます。このAPIは、クライアントとサーバーの両方のアプリケーションをサポートしています。javax.security.sasl.Saslクラスを使用して、SaslClientおよびSaslServerオブジェクトを作成します。

SASLメカニズムの実装は、プロバイダ・パッケージで提供されます。各プロバイダは、1つ以上のSASLメカニズムをサポートする場合があり、標準プロバイダ・アーキテクチャによって登録されて呼び出されます。

Javaプラットフォームには、次のSASLメカニズムを実装する組込みプロバイダが含まれています。

• CRAM-MD5、DIGEST-MD5、EXTERNAL、GSSAPI、NTLM、およびPLAINクライアント・メカニズム
• CRAM-MD5、DIGEST-MD5、GSSAPI、およびNTLMサーバー・メカニズム

Javaプラットフォームには、Generic Security Service Application Programming Interface (GSS-API)用のJava言語バインディングを持つAPIが含まれています。これは、java.security.jgssモジュール内にあります。GSS-APIにより、アプリケーション・プログラマは、様々な基盤となるセキュリティ・メカニズム上のセキュリティ・サービスに統一されたアクセスができます。Java GSS-APIでは現在Kerberos v5メカニズムを使用する必要があり、Javaプラットフォームにはこのメカニズムの組込み実装が含まれています。現時点では、追加のメカニズムをプラグインすることはできません。

Javaプラットフォームには、Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) GSS-APIメカニズムの組込み実装も含まれています。

2つのアプリケーションがGSS-APIを利用して安全にメッセージを交換するには、事前にジョイント・セキュリティ・コンテキストを確立しておく必要があります。コンテキストは、共有状態の情報(暗号化キーなどを含む)をカプセル化します。両方のアプリケーションが、org.ietf.jgss.GSSContextオブジェクトを作成および使用して、セキュリティ・コンテキストを構成する共有情報の確立および保守を行います。セキュリティ・コンテキストが確立されると、安全なメッセージ交換を準備するために使用できます。

Java GSS APIはorg.ietf.jgssパッケージ内にあります。Javaプラットフォームは、KerberosPrincipal、KerberosTicket、KerberosKey、KeyTabなど、基本的なKerberosクラスも定義します。これらはjavax.security.auth.kerberosパッケージ内にあります。

アクセス権は、システム・リソースへのアクセスを表します。アプレット(またはセキュリティ・マネージャとともに実行するアプリケーション)が、リソースへのアクセスを許可されるためには、アクセスを試みるコードに対し、該当するアクセス権を明示的に与える必要があります。

Javaコードがクラス・ローダーによってJava Runtimeにロードされると、クラス・ローダーは次の情報をそのコードに自動的に関連付けます。

• コードのロード元の場所
• コードに署名した人(存在する場合)
• コードに付与されたデフォルトのアクセス権

この情報は、コードが信頼されないネットワークからダウンロードされたか(アプレットなど)、ファイル・システムからロードされたか(ローカル・アプリケーションなど)に関係なく、コードに関連付けられます。コードのロード元の場所はURLで表され、コード署名者は署名者の証明書チェーンによって表され、デフォルトのアクセス権はjava.security.Permissionオブジェクトによって表されます。

ダウンロードされたコードに自動的に付与されるデフォルトのアクセス権には、コードの出所であるホストへのネットワーク接続を行う機能が含まれています。ローカル・ファイル・システムからロードされたコードに自動的に付与されるデフォルトのアクセス権には、コードの出所であるディレクトリおよびそのディレクトリのサブディレクトリからファイルを読み取る機能が含まれています。

コードを実行しているユーザーのアイデンティティは、クラス・ローディング時に利用できません。アプリケーション・コードで、必要に応じてエンド・ユーザーを認証する必要があります(認証の項を参照)。ユーザーが認証されると、javax.security.auth.SubjectクラスのdoAsメソッドを呼び出すことによって、アプリケーションはそのユーザーを実行コードに動的に関連付けることができます。

クラスローダによって、限られた一連のデフォルト・アクセス権がコードに付与されます。管理者は、セキュリティ・ポリシーによって、追加のコード・アクセス権を柔軟に管理できます。

Java SEは、セキュリティ・ポリシーの概念をjava.security.Policyクラスにカプセル化します。Java RuntimeにインストールされるPolicyオブジェクトはいつでも1つのみです。Policyオブジェクトの基本的な役割は、保護されたリソースへのアクセスがコード(ロード元の場所、署名者、および実行者によって特徴付けられる)に許可されるかどうかを決定することです。Policyオブジェクトがこの決定を行う方法は、実装によって異なります。たとえば、承認データを含むデータベースに問い合わせたり、別のサービスに問い合わせたりする場合があります。

Java SEには、セキュリティ・プロパティ・ファイル内に構成された1つ以上のASCII (UTF-8)ファイルから承認データを読み込む、デフォルトのPolicy実装が含まれています。これらのポリシー・ファイルには、コードに付与されるアクセス権の厳密なセットが含まれています。具体的には、特定の場所からロードされ、特定のエンティティによって署名され、特定のユーザーとして実行されるコードに付与されるアクセス権の厳密なセットです。各ファイル内のポリシー・エントリは、ドキュメント化された独自の構文に準拠する必要があり、単純なテキスト・エディタを使用して作成できます。

Java Runtimeは、プログラムの実行時に行われた一連のJava呼出しを追跡します。保護されたリソースへのアクセスが要求された場合、デフォルトでは、要求されたアクセスを許可するかどうかを決定するために呼出しスタック全体が評価されます。

前述したように、リソースはSecurityManagerによって保護されます。JDK内およびアプリケーション内の、セキュリティの影響を受けるコードは、次のようなコードでリソースへのアクセスを保護します。

SecurityManager sm = System.getSecurityManager();
if (sm != null) {
   sm.checkPermission(perm);
}

Permissionオブジェクトpermは、要求されたアクセスに対応します。たとえば、ファイル/tmp/abcを読み取ろうとすると、アクセス権は次のように構成される場合があります。

Permission perm = new java.io.FilePermission("/tmp/abc", "read");

SecurityManagerのデフォルトの実装は、その決定をjava.security.AccessController実装に委譲します。AccessControllerは、呼出しスタックをトラバースして、スタック内の各コード要素を、要求されたアクセス権(たとえば、前述の例ではFilePermission)とともに、インストールされているセキュリティPolicyに渡します。Policyは、管理者によって構成されたアクセス権に基づいて、要求されたアクセスを付与するかどうかを決定します。アクセスが付与されない場合、AccessControllerはjava.lang.SecurityException.をスローします。

図1-4は、アクセス制御の適用を示しています。この特定の例では、最初に2つの要素ClassAおよびClassBが呼出しスタックにあります。ClassAは、ClassB内のメソッドを呼び出します。これは次に、java.io.FileInputStreamのインスタンスを作成することで、ファイル/tmp/abcへのアクセスを試みます。FileInputStreamコンストラクタは、FilePermission、permを作成してから、前述のように、permをSecurityManagerクラスのcheckPermissionメソッドに渡します。この特定の例では、ClassAおよびClassBのアクセス権のみをチェックする必要があります。これは、FileInputStream、SecurityManagerおよびAccessControllerなど、java.baseモジュール内のすべてのクラスは、すべてのアクセス権を自動的に受け取るためです。

この例では、ClassAとClassBには異なるコード特性があります(出所および署名者が異なります)。それぞれに異なるアクセス権が付与されている場合があります。要求されたFilePermissionが両方のクラスに付与されていることをPolicyが示した場合にのみ、AccessControllerは要求されたファイルへのアクセスを付与します。

図1-4 リソースへのアクセスの制御

「図1-4 リソースへのアクセスの制御」の説明