1. Oracle GoldenGate環境の保護
  2. マイクロサービス・アーキテクチャの保護
  3. 通信セキュリティ

4 通信セキュリティ

通信セキュリティは、TCP/IPベースのネットワークなどの通信チャネル上で送信される情報の機密性と整合性です。

トピック:

親トピック: マイクロサービス・アーキテクチャの保護

証明書アクセス制御リスト

通信セキュリティを強化する方法を学習します。

通信セキュリティは、接続ハンドシェイク・プロセス中に有効な証明書を受け入れます。ただし、内部ポリシーに基づいて有効な証明書をフィルタ処理して拒否することが必要な場合があります。たとえば、財務部門は、人事証明書が暗号的に有効であっても、人事部に発行された証明書を拒否できます。この追加の検証をサポートするために、MAは検証後の証明書のアクセス制御リスト(ACL)管理を追加することにより、標準的な証明書検証を拡張します。この証明書ACLは、ネットワークACLに使用される一般的なモデルに従います。ここで、ACLは、管理対象要素を識別するキーと、その要素が許可または拒否されているかどうかを示す値のマップです。certACLエントリは、ACLエントリを証明書内の特定の識別要素に適用できるscope仕様を持っています。

証明書ACLの構成は、certACLエントリ構成仕様の配列形式を使用します。それぞれの仕様は、最小限、その仕様が指定アドレスからのクライアント接続を許可するか拒否するかを示す許可文を含んでいます。certACLエントリ仕様は順番に処理され、指定アドレスが適格と認定され次第終了します。指定アドレスが適格と認定されない場合、処理は次の仕様を続けます。証明書が適格と認定されると、certACL権限は証明書が許可されるか拒否されるかを決定します。certACLエントリ仕様が、接続を要求しているクライアントの証明書を適格と認定しない場合、デフォルトの解決方法の「許可」が仮定され、証明書が受け入れられます。

CertACLエントリの構文 

certACL := '[' aclSpec [, aclSpec] ']'
  aclSpec    := '{' perm [',' name [',' scope '}'
  perm       := "permission" ':' [ "deny" | "allow" ]
  name       := "name"       ':' regex 
  scope      := "scope"      ':' [ "subject-name" | "issuer-name" ]
  regex      :=  ** Uses the dynamic regular expression syntax.

regex構文はECMAScriptの定義に従います。正規表現をJSONノード値として定義するには、(\sのように)使用されるすべてのメタ・シンボルが\文字をエスケープする必要があります。名前の正規表現パターンを指定するときは、意図したターゲット・パターンとの完全一致のみが一致するように注意する必要があります。構文では、マッチ・パターンにパターンをバインドするデリミタの指定が含まれているため、 CN=AdminClnt1、CN=AdminClntOther、CN=OtherAdminClntまたはCCN=OtherAdminClntではなく目的のパターンCN=AdminClntと完全に一致します。これらのパターンでは、キー名と値の間の空白が許可されていない標準識別名形式を想定しています。CN = AdminClntの非標準パターンは一致しません。

例4-1 すべての証明書を許可する例

 "CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=AdminClnt)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "permission" : "deny" } ]

または

"CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=AdminClnt)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "scope" : "subject-name", "permission" : "deny" } ]

例4-2 Deploy2から発行された証明書の拒否

 "CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=Deploy2)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "scope" : "issuer-name", "permission" : "deny" } ]

例4-3 Suspectに発行された証明書またはDeploy2により発行された任意の証明書

 "CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=Suspect)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "scope" : "subject-name", "permission" : "deny" }, { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=Deploy2)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "scope" : "issuer-name",  "permission" : "deny" } ]

親トピック: 通信セキュリティ

トランスポート・レイヤー・セキュリティ・プロトコルと暗号

サポートされているセキュリティ・プロトコルを確認します。

トランスポート・レイヤー・セキュリティ(TLS)プロトコル

サポートされているプロトコルのバージョンは次のとおりで、これらは/config/securityDetails/network/common/protocolVersionセキュリティ設定を設定する際に使用可能な値です。

プロトコル・バージョンID ノート

3_0_With_2_0_Hello

 

3_0_Only

 

2_0

非推奨とみなされます。

3_0

 

1_0

 

1_0_Or_3_0

 

1_0_Or_3_0_Or_2_0

 

3_0_Or_2_0

 

1_1

 

1_2

 

1_1_Or_3_0

 

1_2_Or_3_0

 

1_1_Or_1_0

 

1_2_Or_1_0

 

1_2_Or_1_1

 

1_1_Or_1_0_Or_3_0

 

1_2_Or_1_0_Or_3_0

 

1_2_Or_1_1_Or_1_0

Oracle推奨

1_2_Or_1_1_Or_3_0

 

1_2_Or_1_1_Or_1_0_Or_3_0

 

TLSバージョン・サポートのクライアント・サポートの検証が必要なため、テストでは、特定のTLSプロトコル・バージョンに使用されているすべてのクライアントが、テストされているTLSバージョンをサポートしていることを確認する必要があります。診断的には、ハンドシェイク・プロトコル処理のためにサーバー・ログを確認する必要があります。ログは、交渉中のプロトコル・バージョンを含む必要があります。クライアントがサーバーが構成されているプロトコルのバージョンをサポートしていない場合、サーバーは接続を終了します。プロトコル・バージョンが失敗したことを明示的にクライアントに送信するエラー・メッセージまたは指示が表示されないことがあります。エラーは、クライアントがどのように例外処理をするように設定されているかに応じて、ネットワーク接続拒否または証明書エラーとしてクライアントに表示されることがあります。

注意:

セキュリティ上の欠陥が文書化されているため、1.0バージョン未満のTLSプロトコルは使用しないでください。

TLSセキュリティ暗号スイート

サポートされているセキュリティ暗号スイートは次のとおりで、これらは/config/securityDetails/network/common/cipherSuitesセキュリティ設定を設定する際に使用可能な値です。

暗号スイートID ノート

TLS_NO_SUCH_CIPHERSUITE

 

TLS_RSA_WITH_RC4_128_MD5

 

TLS_RSA_WITH_RC4_128_SHA

 

TLS_RSA_WITH_3DES_EDE_CBC_SHA

米国連邦情報処理標準(FIPS)準拠

TLS_RSA_WITH_DES_CBC_SHA

 

TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

 

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

 

TLS_DH_anon_WITH_RC4_128_MD5

 

TLS_DH_anon_WITH_DES_CBC_SHA

 

TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

FIPS準拠

TLS_RSA_WITH_AES_128_CBC_SHA

FIPS準拠

TLS_RSA_WITH_AES_256_CBC_SHA

FIPS準拠

TLS_RSA_WITH_AES_128_CBC_SHA256

FIPS準拠

TLS_RSA_WITH_AES_128_GCM_SHA256

FIPS準拠

TLS_RSA_WITH_AES_256_GCM_SHA384

FIPS準拠

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

FIPS準拠の楕円曲線暗号方式(ECC)の暗号

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

FIPS準拠のECC暗号

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

FIPS準拠のECC暗号

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

FIPS準拠のECC暗号

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

FIPS準拠のECC暗号

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

FIPS準拠(?)ECC暗号

ECC暗号は、有限体上の楕円曲線の代数構造に基づいています。楕円曲線離散対数問題(ECDLP)は、既知の基点に対するランダム楕円曲線要素の離散対数を見つけることは実行不可能であると仮定しています。ECC暗号の利点は、一般的に、非ECC暗号同等物に比べて鍵サイズが小さいことです。

親トピック: 通信セキュリティ

TLS証明書失効リストの処理

証明書の失効リストを構成する方法を学習します。

証明書失効リスト(CRL)は、失効リストの発行者を識別する情報と、失効した証明書を識別するゼロ個以上のエントリが続く情報を含むPrivacy Enhance Mail (PEM)形式のファイルです。保護されたサーバーは、ピアとの安全なチャネルを確立することの一部であり、ピアとのハンドシェイクを開始します。このハンドシェイク中に、セキュリティ情報と機能が交渉され、交換されます。これには参加者の一方または両方の証明書が含まれます。セキュリティ構成に応じて、参加者の一方または両方がピアの証明書を提示したり必要とする場合や、どちらもその必要がない場合もあります。

ピアのX.509証明書を受信してその有効性を​​検証した後、受信側参加者は現在設定されているCRLを調べます。検証直後のピア証明書を識別するエントリが存在すると、受信側参加者は、リモート参加者の証明書を失効済と見なします。失効した証明書は、リモート参加者のアイデンティティの認証には無効とみなされます。失効した証明書は、セキュア・チャネル・ハンドシェイクの完全性チェック部分に失敗し、チャネルを終了します。リモート・ピアが証明書の検証中にエラーが発生したことを検出する実装によっては、特定の原因について通知されないことがあります。

実際のCRLはプロローグで構成され、0個以上のエントリが続くCRLの発行者を識別します。各エントリは、失効日、署名アルゴリズム、指紋情報に関するセキュリティ情報とともに、シリアル番号で特定の証明書を識別します。

次に例を示します。

Certificate Revocation List (CRL):
        Version 2 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: /C=US/ST=CA/L=Redwood Shores/O=Oracle Corp/OU=Corporate Security/OU=Deployment Security/CN=Deploy1
        Last Update: Feb 22 19:20:34 2017 GMT
        Next Update: Mar 24 19:20:34 2017 GMT
        CRL extensions:
            X509v3 Authority Key Identifier:
                keyid:7C:A0:BB:FB:6F:75:70:4B:B4:95:18:54:9C:1F:88:2E:A1:1B:EF:E4
 
            X509v3 CRL Number:
                4097
Revoked Certificates:
    Serial Number: 1000
        Revocation Date: Feb 22 19:20:34 2017 GMT
    Signature Algorithm: sha256WithRSAEncryption
         a6:e5:75:62:93:49:26:6e:79:f1:dd:90:94:bb:99:1c:3a:24:
         99:63:82:d6:f1:56:72:98:cc:8f:6f:61:b8:a4:dd:21:0f:ae:
         fa:38:78:c0:c9:bc:bc:87:61:15:35:e7:20:b8:5e:8f:6a:0a:
         e1:58:e0:30:6d:df:03:8f:6f:de:0a:54:1c:f0:44:e5:28:48:
         56:23:00:60:19:dd:e2:68:2d:35:2b:cc:62:85:b6:34:32:ce:
         c3:f6:8a:b0:bb:b4:66:0e:85:8c:79:b2:32:5c:65:ac:47:99:
         69:c5:bf:bb:ec:1e:7f:40:e2:1f:11:fa:2a:7c:d3:94:de:62:
         e2:8b:de:15:04:2c:67:14:2e:b7:71:29:d5:e2:e1:ee:ac:c3:
         a3:d0:20:41:a9:e0:6a:5b:90:28:35:5a:90:86:51:69:df:27:
         af:3e:0f:c0:d2:32:ab:d2:7a:c5:16:29:f6:ec:04:dd:e7:6d:
         8b:10:06:40:c0:08:32:39:50:33:c0:b9:86:b9:77:19:6f:a6:
         49:65:54:f5:35:c8:27:08:f6:fa:91:3c:ae:2c:b5:c1:52:de:
         42:2c:65:6c:ce:97:52:50:00:53:df:6d:1d:e6:38:9f:61:97:
         d9:aa:60:1c:06:24:aa:f3:ac:8c:d6:85:ed:83:20:2f:50:5c:
         f6:af:78:91:49:a5:b7:cb:96:6c:03:3a:e3:3d:dd:a9:d5:0f:
         5f:3c:47:8c:78:33:65:09:65:8a:08:92:19:58:a1:93:7f:99:
         ee:9d:f1:4a:30:21:63:24:5a:d4:6b:bd:e0:ec:0c:79:09:1f:
         48:a6:39:87:92:0b:f7:25:8e:31:65:ee:10:28:45:bb:55:9c:
         c8:64:49:fe:1d:78:6d:9a:09:67:6b:76:f4:3f:6a:b8:eb:c0:
         0b:0c:ab:92:6d:f5:60:06:34:0f:ef:65:be:c8:af:1d:67:bc:
         36:b7:d1:c0:ea:30:71:3b:2b:ba:16:dc:72:86:90:32:e3:59:
         99:2c:33:7a:2f:63:77:ec:0d:70:89:52:0f:8f:29:13:fd:17:
         18:49:56:65:8d:23:64:ba:e9:b6:74:56:40:9b:1c:65:17:ef:
         bd:2c:77:d4:69:f6:f4:eb:df:a9:31:14:89:fc:1d:24:81:7d:
         85:ba:1d:8f:8b:1b:0d:c2:a3:c2:ea:a5:6e:a2:a7:be:34:16:
         a1:b8:16:a4:f2:32:5a:65:2d:85:14:be:73:6b:de:40:13:bd:
         f1:3d:7e:65:14:3c:a8:ad:b7:4e:cb:41:53:f4:24:5a:4f:a1:
         56:b6:33:65:f9:ef:b9:40:2d:26:ee:ba:57:d5:f5:75:1b:60:
         8d:f2:24:36:e5:2a:c8:b3
-----BEGIN X509 CRL-----
MIIDKjCCARICAQEwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAlVTMQswCQYD
VQQIDAJDQTEXMBUGA1UEBwwOUmVkd29vZCBTaG9yZXMxFDASBgNVBAoMC09yYWNs
ZSBDb3JwMRswGQYDVQQLDBJDb3Jwb3JhdGUgU2VjdXJpdHkxHDAaBgNVBAsME0Rl
cGxveW1lbnQgU2VjdXJpdHkxEDAOBgNVBAMMB0RlcGxveTEXDTE3MDIyMjE5MjAz
NFoXDTE3MDMyNDE5MjAzNFowFTATAgIQABcNMTcwMjIyMTkyMDM0WqAwMC4wHwYD
VR0jBBgwFoAUfKC7+291cEu0lRhUnB+ILqEb7+QwCwYDVR0UBAQCAhABMA0GCSqG
SIb3DQEBCwUAA4ICAQCm5XVik0kmbnnx3ZCUu5kcOiSZY4LW8VZymMyPb2G4pN0h
D676OHjAyby8h2EVNecguF6PagrhWOAwbd8Dj2/eClQc8ETlKEhWIwBgGd3iaC01
K8xihbY0Ms7D9oqwu7RmDoWMebIyXGWsR5lpxb+77B5/QOIfEfoqfNOU3mLii94V
BCxnFC63cSnV4uHurMOj0CBBqeBqW5AoNVqQhlFp3yevPg/A0jKr0nrFFin27ATd
522LEAZAwAgyOVAzwLmGuXcZb6ZJZVT1NcgnCPb6kTyuLLXBUt5CLGVszpdSUABT
320d5jifYZfZqmAcBiSq86yM1oXtgyAvUFz2r3iRSaW3y5ZsAzrjPd2p1Q9fPEeM
eDNlCWWKCJIZWKGTf5nunfFKMCFjJFrUa73g7Ax5CR9IpjmHkgv3JY4xZe4QKEW7
VZzIZEn+HXhtmglna3b0P2q468ALDKuSbfVgBjQP72W+yK8dZ7w2t9HA6jBxOyu6
FtxyhpAy41mZLDN6L2N37A1wiVIPjykT/RcYSVZljSNkuum2dFZAmxxlF++9LHfU
afb069+pMRSJ/B0kgX2Fuh2PixsNwqPC6qVuoqe+NBahuBak8jJaZS2FFL5za95A
E73xPX5lFDyorbdOy0FT9CRaT6FWtjNl+e+5QC0m7rpX1fV1G2CN8iQ25SrIsw==
-----END X509 CRL-----

通常、コンパクトな形式のCRLでは、-----BEGIN X509 CRL-----と-----END X509 CRL-----デリミタの間のコンテンツのみを組み込みます。これらのデリミタの外側にある他のデータはすべて無視されます。CRLの機能に影響を与えずに、CRLのテキスト表現をCRLファイルに埋め込むことができます。

CRLの使用は、各MAサーバーごとに個別に構成されています。CRL構成は、次の2つのプロパティで構成されています。

/config/security/common/crlEnabled

CRL処理を有効または無効にします。

ただし、 /config/security/common/crlEnabled が有効(true)の場合、 /config/security/common/crlStore プロパティは有効で整形式のCRLを参照する必要があります。

/config/security/common/crlStore

CRL処理が無効(false)の場合、リモート参加者の証明書はCRLと照合されません。この場合、/config/security/common/crlStoreプロパティを設定する必要はありません。

有効かつ整形式のCRLファイルは、RFC 2380 - インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト(CRL)プロファイルまたは空のファイルに準拠するPEMエンコードCRLファイルです。

次に、セキュリティ保護されたサーバーにCRL処理を宣言および定義するサンプルの抜粋を示します。

{
    "config" : {
        "security: {
            "common" : {
                "crlEnabled" : true,
                "crlStore"   : "file:/scratch/Tests.SCA/unittests/etc/ssl/RootCA/CAs/Deploy1/CRLs/empty_CRL.pem"
            }
        }
    }
}

CRLファイルは、サーバーの稼働中に他の、おそらくより最新のバージョンによって更新または置き換えられます。CRLファイルを置き換えると、次回の要求CRL参照で新しく更新されたファイルが使用されます。

/config/security/common/crlEnabledプロパティの設定方法に関係なく、サーバーの一般的なセキュリティ構成が無効になっている場合、CRL処理が無効になります。たとえば、/config/securityプロパティの値は、false)です。

間接的にCRL処理に影響するもう1つの構成設定は、/config/securityDetails/network/common/authModeプロパティです。このプロパティは、サーバーが証明書を使用してクライアントを認証する必要があるかどうか、またはサーバーがオプションで提示された証明書を受け入れるかどうか、またはサーバーが提示されたクライアント証明書を無視するかどうかを制御します。証明書が必須ではなく、提示されない、またはサーバーによって無視される場合、CRL処理は使用されません。

親トピック: 通信セキュリティ

HTTPセキュリティとキャッシュ・ヘッダー

サポートされているセキュリティとキャッシュ・ヘッダーを確認します。

MAサーバーは、サーバー、クライアントおよびプロキシがHTTPコンテンツをどのように処理するかを制御する一連のヘッダーを含むHTTPエンベロープを受け入れて返します。HTTPの詳細は、次を参照してください。

セキュリティ・ヘッダー

発行可能なセキュリティ・ヘッダーは次のとおりです。

Content-Security-Policy (CSP)

CSPはサーバー・レスポンスのヘッダーとして組み込まれ、クライアントがサーバーから送信されたコンテンツをどのように処理するかを定義します。

デフォルトのCSPヘッダー文は次のとおりです。

Content-Security-Policy: script-src 'self' 'unsafe-eval' 'unsafe-inline'

オプションは次のとおりです。

  • script-src:

  • unsafe-eval:

  • unsafe-inline:

X-Frame-Options

X-Frame-Optionsはサーバー・レスポンスでヘッダーとして含まれ、ユーザー・エージェントが<frame>、<iframe>、<object>内でコンテンツをレンダリングできるようにするかどうかをクライアントに通知します。Webサイトは、<frame>および<iframe>を使用してマッシュアップを作成したり、1つのサイトの一部を埋め込みます。ただし、埋込みサイトをClickjack攻撃に公開します。このディレクティブは、コンテンツが同じサイト(起点)からのものでないかぎり、クライアントがコンテンツを埋込みとしてレンダリングすることを禁止します。

デフォルトのX-Frame-Options文は次のとおりです。

X-Frame-Options: SAMEORIGIN

オプションは、SAMEORIGINです。

X-XSS-Protection

X-XSS-Protectionは、サーバー・レスポンスのヘッダーとして組み込まれ、ユーザー・エージェントの埋込みXSS (クロスサイト・セキュリティ)保護を構成します。オプションは有効化、無効化、およびブロックとレポートとの組合せが可能です。

デフォルトのX-XSS-Protection文は次のとおりです。

X-XSS-Protection: 1; mode=block

オプションは次のとおりです。

  • 1: ユーザー・エージェントの保護モードを有効にします。

  • 2: ユーザー・エージェントの保護モードを無効にします。

  • mode=block: コンテンツ・スクリプトがユーザー入力として注入された場合、サーバーのレスポンスをブロックします。

  • mode-report=url: 潜在的なXSS攻撃を指定されたURLに報告します。ChromeとWebKitでのみサポートされます。

X-Content-Type-Options

デフォルトのX-Content-Type-Options文は次のとおりです。

  X-Content-Type-Options: nosniff

オプションはnosniffです。

キャッシュ・ヘッダー

サポートされるキャッシュ・ヘッダーは次のとおりです。

Cache-Control

デフォルトのCache-Control文は次のとおりです。

Cache-Control: no-cache, no-store, must-revalidate
Pragma

デフォルトのPragma文は次のとおりです。

Pragma: no-cache
Expires

デフォルトのExpires文は次のとおりです。

Expires: 0

親トピック: 通信セキュリティ