ホーム
保護
このセクションでは、操作制御リスト、ID、TLS などのセキュリティー機能について説明します。
TLS セキュリティー
TLS (Transport Layer Security) は、TCP/IP プロトコル経由で実行する Domino® サーバー・タスクの通信上の機密性を保護し、認証を行うためのセキュリティー・プロトコルです。
証明書マネージャーで TLS 証明書を管理する
HCL Domino® 12 は、Domino 環境で TLS 証明書を管理するために、新しいデータベースの証明書ストア (certstore.nsf) と連携する新しいサーバー・タスク、証明書マネージャー (CertMgr) を導入しました。
Let's Encrypt CA を使用して証明書を管理する
CertMgr は、ACME プロトコルを使用して、Let's Encrypt® 認証局 (CA) から、信頼できる無料の TLS 証明書を自動的に要求、構成、更新する機能を提供することで、Domino Web サーバーの操作を簡素化し、セキュリティーを確保します。
HTTP-01 チャレンジのための Let's Encrypt 証明書要求フロー
次の図は、HTTP-01 チャレンジが使用される場合の Let's Encrypt® CA への証明書要求に関連するコンポーネントと手順を示しています。

保護
このセクションでは、操作制御リスト、ID、TLS などのセキュリティー機能について説明します。
- Domino のセキュリティーの概要
  組織のセキュリティーを設定することは、非常に重要なタスクです。組織の IT リソースと資産を保護するためには、セキュリティーのインフラストラクチャが重要な役割を果たします。システム管理者は、サーバーまたはユーザーの設定を実行する前に、組織のセキュリティ要件を慎重に考慮する必要があります。最新の情報を把握してプランニングを行うと、セキュリティ侵害のリスクを最小限に抑えることができます。
- Notes® ユーザー、インターネットユーザー、Domino® サーバーのサーバーへのアクセス
  Domino® では、ユーザーやサーバーから他のサーバーへのアクセスは、検証と認証のルールに加え、サーバー文書の [セキュリティ] タブで設定した内容に従って制御されます。Notes® ユーザー、インターネットユーザー、サーバーは、サーバーに検証および認証され、サーバー文書の設定内容でアクセスが許可されていれば、そのサーバーにアクセスできます。
- データベースのアクセス制御リスト
  各データベースにはアクセス制御リスト (ACL) が 1 つずつあります。ACL は、ユーザーとサーバーがそのデータベースに実行できるアクセスのレベルを指定します。割り当てるアクセスレベルの名前は、サーバーの場合もユーザーの場合も同じです。ただし、ユーザーに割り当てたアクセスレベルからはユーザーがデータベース内で実行できるタスクが決まり、サーバーに割り当てたアクセスレベルからはサーバーがデータベースのどの情報を複製できるかが決まります。ACL の作成や更新を行うには、[管理者] 以上のアクセス権が必要です。
- Domino® サーバー ID と Notes® ユーザー ID
  Domino® は、ID ファイルを使用して、ユーザーを識別し、サーバーへのアクセスを制御します。すべての Domino サーバー、Notes® 認証者、Notes ユーザーは、ID を持つ必要があります。
- 実行制御リスト
  操作制御リスト (ECL) を使用して、クライアントデータのセキュリティを設定します。ECL を使用すると、送信元が不明であったり疑わしい送信元から送られたアクティブコンテンツからクライアントを保護することができます。
- Domino® サーバーベース認証機関
  認証要求の管理と処理を行うには、CA プロセスサーバータスクを使用するように Domino® 認証機関を設定します。CA プロセスは、証明書の発行に使用される Domino サーバー上でプロセスとして実行されます。Notes® 認証者またはインターネット認証者を設定する際、サーバー上の CA プロセスにリンクするように設定すると、CA プロセスの機能を利用できます。1 台のサーバー上で実行できる CA プロセスのインスタンスは、1 つだけです。ただし、CA プロセスは、複数の認証者にリンクできます。
- TLS セキュリティー
  TLS (Transport Layer Security) は、TCP/IP プロトコル経由で実行する Domino® サーバー・タスクの通信上の機密性を保護し、認証を行うためのセキュリティー・プロトコルです。
  - 証明書マネージャーで TLS 証明書を管理する
    HCL Domino® 12 は、Domino 環境で TLS 証明書を管理するために、新しいデータベースの証明書ストア (certstore.nsf) と連携する新しいサーバー・タスク、証明書マネージャー (CertMgr) を導入しました。
    - CertMgr を実行する
      CertMgr が自動的に起動するように設定するには、CertMgr を ServerTasks notes.ini 設定に追加するか、プログラム文書で実行するようにスケジュールします。初回実行時に、証明書ストア・データベース (certstore.nsf) が作成されます。
    - グローバル設定を構成する
      グローバル設定を構成して、証明書管理に使用するデフォルト値を設定します。
    - Let's Encrypt CA を使用して証明書を管理する
      CertMgr は、ACME プロトコルを使用して、Let's Encrypt® 認証局 (CA) から、信頼できる無料の TLS 証明書を自動的に要求、構成、更新する機能を提供することで、Domino Web サーバーの操作を簡素化し、セキュリティーを確保します。
      - Let's Encrypt CA 証明書要求: クイック・スタート
        HCL Domino® サーバーが発信ポート 443 および着信ポート 80/443 を介してインターネットに接続されている場合は、CertMgr コマンドを使用して Let's Encrypt CAからサーバーの証明書を要求できます。
      - Let's Encrypt CA チャレンジ・オプション
        ユーザーが Let’s Encrypt CA から証明書を受け取ると、Let’s Encrypt CA サーバーはチャレンジを使用して、ユーザーが証明書のドメイン名を管理していることを検証します。サポートされているチャレンジには 2 つのタイプがあり、どちらも Domino で使用できます。
      - Let's Encrypt CA から証明書を要求するための Domino サーバーを準備する
        Let's Encrypt® CA から証明書を要求するために Domino サーバーを準備するには、使用するチャレンジのタイプに対応する手順 (HTTP-01 または DNS-01) に従います。HTTP-01 は、最も一般的に使用されるチャレンジです。
      - ACME アカウント・プロファイルを構成する
        Let's Encrypt CA に最初の証明書要求を送信する前に構成する certstore.nsf には、2 つの ACME アカウント・プロファイル文書があります。
      - Let's Encrypt CA からの明書を要求する
        certstore.nsf インターフェースを使用して Let's Encrypt® CA から証明書を要求します。
      - HTTP-01 チャレンジのための Let's Encrypt 証明書要求フロー
        次の図は、HTTP-01 チャレンジが使用される場合の Let's Encrypt® CA への証明書要求に関連するコンポーネントと手順を示しています。
    - サードパーティ CA からの鍵と証明書を要求してインポートする
      HCL Domino® 12 以降、Domino サーバー上でサードパーティーの認証局 (CA) からのインターネット証明書を構成するプロセスがより簡単になりました。
    - 既存の資格情報をインポートする
      TLS 資格情報文書にまだ追加されていない TLS 資格情報がディスク上にある場合は、certstore.nsf データベースを使用してインポートして、CertMgr で使用することができます。
    - 資格情報をファイルにエクスポートする
      TLS 資格情報文書の資格情報をファイルにエクスポートできます。
    - 信頼されたルート証明書を追加する
      信頼されたルート証明書を使用すると、Web サーバーは、接続しているクライアントから信頼されたルート証明書を受け入れることができます。信頼されたルート証明書は、CA が提示する部分的な証明書チェーンを自動的に完成させる場合にも役立ちます。
    - Micro CA から証明書を作成する
      Micro CA から Web サーバー TLS 証明書を作成できます。
    - ACME アカウントおよびホスト鍵の ECDSA 暗号化のサポート
      CertMgr は、ACME アカウントおよび Let's Encrypt® CA またはサードパーティ CA から生成された TLS 1.2 ホスト鍵 (キーリング・ファイル) の NIST P-256 および NIST P-384 曲線を使用した楕円曲線デジタル署名アルゴリズム (ECDSA) をサポートしています。
    - キー・ロールオーバーを要求する
      TLS ホストのキー・ロールオーバー (より一般的な) または ACME アカウントのキー・ロールオーバーを要求できます。
    - CertMgr コマンドライン・パラメーター
      load certmgr コマンドは、以下のパラメーターを使用して実行できます。
    - CertMgr tell コマンド
      次の CertMgr tell コマンドがあります。
    - CertMgr notes.ini 設定
      CertMgr には、以下の notes.ini 設定が含まれています。一部のパラメーターには、コマンドライン・パラメーターと同等の値が含まれているので、注意が必要です。
    - 証明書の正常性チェック
      CertMgr タスクは、インポートされた鍵と証明書の正常性を、インポート時とその後 30 分ごとにチェックします。
    - CertMgr デバッグ・ロギング
      CertMgr デバッグ・ロギングを有効にするために使用される load certmgr -d コマンドには、トラブルシューティング情報を 1 か所で提供する通常のメッセージ・ロギングも含まれています。このロギングは、Let's Encrypt 認証局とサードパーティ CA からの証明書に関連しています。
  - TLS ポート構成
    TLS プロトコルでは、暗号化されて整合性チェックが行われる通信チャネルと認証済みサーバー ID が常に提供されます。TLS サーバーを設定して、さまざまな形式のクライアント ID 認証を要求することもできます。
  - サーバーに TLS 接続を要求する
    クライアントが保護された接続を使用してサーバーのデータベースにアクセスするようにしたい場合は、TLS 接続を要求します。その場合は、TCP/IP ポートを介して受信した接続要求を TLS ポートにリダイレクトします。TLS 接続が不要な場合、クライアントは TLS または TCP/IP のいずれかを使用してサーバーに接続できます。
  - サーバー間 TLS 用のインターネット相互認証を作成する
    信頼性の確立を目的として、あるサーバーが別のサーバーからインターネット相互認証を取得することができます。たとえばサーバーが別のサーバーのディレクトリアシスタントにアクセスする必要がある場合などです。
  - TLS クライアントのデータベースへのアクセス権を設定する
    Domino® サーバーで TLS を設定したら、サーバーのデータベースへのアクセス権をクライアントに与える必要があります。
  - TLS 暗号に関する制限を変更する
    TLS では、パブリック・キー、プライベート・キー、セッションで決定するセッション・キーが使用されます。どの TLS 証明書のセットでも、パブリック・キーとプライベート・キーのペアと、証明書の所有者がネットワーク上で自分自身を識別したり、S/MIME を使用してメッセージを暗号化しメッセージに署名したりすることを可能にする X.509 証明書があります。証明書には、キー・ペアのうち、パブリックキーだけが含まれます。プライベートキーは、Notes® クライアントの ID ファイルに格納されます。TLS サーバーの場合は、キー・リング・ファイルまたは cerstore.nsf データベースに格納されます。Domino 12 以降、Domino は RSA キーと ECDSA キーの両方をサポートしています。詳しくは、wn_ECDSA_cryptography.htmlを参照してください。
  - 2 次 Domino® ディレクトリーと LDAP ディレクトリーで Web TLS クライアントを認証する
    サーバーで Web クライアント認証を行う場合、デフォルトでは、1 次 HCL Domino® ディレクトリがチェックされ、クライアント証明書がユーザー文書にあるかどうか確認されます。クライアント証明書の確認に 2 次 Domino ディレクトリや LDAP ディレクトリを使用する場合は、これらのディレクトリもチェックするように Domino を設定できます。これには、2 次 Domino ディレクトリと LDAP ディレクトリをディレクトリアシスタントデータベースで信頼されたドメインとして設定します。
  - TLS セッションの再開
    TLS セッションの再開を利用すると、TLS 使用時のパフォーマンスが大幅に改善されます。直前の成功した TLS セッションのネゴシエーションの情報を再度呼び出すことによって、TLS セッション・キーのネゴシエーションという最も負荷のかかる部分をバイパスできるからです。HTTP は TLS セッションの再開によって最も恩恵を受けるプロトコルですが、他のインターネット・プロトコルにもメリットがあります。
  - 証明書マネージャーを使用せずに TLS 証明書を管理する
    証明書マネージャー (CertMgr) および証明書ストア (certstore.nsf) データベースで証明書を管理しない場合は、このセクションで説明するように、証明書を手動で生成および管理します。
- クライアントの TLS と S/MIME
  クライアントでは、Domino® 認証機関 (CA) アプリケーションかサードパーティ CA を使用して、TLS と S/MIME の接続を保護するための証明書を取得できます。
- 暗号化
  暗号化を使用すると、不正なアクセスからデータを保護できます。
- インターネット/イントラネットクライアントの名前とパスワードによる認証
  基本的なパスワード認証として知られる名前とパスワードによる認証です。ユーザーに名前とパスワードを要求し、Domino® ディレクトリ内のユーザー文書に保存されているパスワードの保護ハッシュと比較してパスワードが正確であるかを検証する、基本的な質問/応答のプロトコルが使用されます。
- 時間ベースのワンタイム・パスワード (TOTP) 認証
  ユーザーが Domino Web サーバーにログオンする場合、ユーザー名とパスワードに加えて、ユーザーが時間ベースのワンタイム・パスワードを提供するように要求できます。
- 複数サーバーのセッションベースの認証 (シングルサインオン)
  シングルサインオン (SSO) とも呼ばれる複数サーバーのセッションベース認証を使用することにより、Web ユーザーは、Domino® サーバーまたは WebSphere® サーバーに一度ログインすると、同一の DNS ドメイン内にあってシングルサインオン (SSO) が有効になっている他の任意の Domino サーバーや WebSphere サーバーに、再度ログインすることなくアクセス可能になります。
- Security Assertion Markup Language (SAML) を使用して統合 ID 認証を設定する
  統合 ID は、シングルサインオンを実現して、ユーザーの利便性を高め、管理コストの削減を図る手段です。IBM Domino® と IBM Notes® では、ユーザー認証用の統合 ID に、OASIS の Security Assertion Markup Language (SAML) 標準が使用されます。
- 資格情報ストアを使用して資格情報を保存する
  Domino® サーバーは、資格情報ストア・アプリケーションをセキュリティーで保護された成果物リポジトリーとして使用できます。セキュリティーで保護された成果物リポジトリーの例としては、認証資格情報とセキュリティー・キーなどがあります。
- Notes と Domino でサポートされる鍵サイズの歴史
  この記事では、Notes® と Domino® でサポートされる RSA 鍵サイズと、過去のリリースから現在のリリースまでの RSA 鍵サイズに関する情報を提供します。

HTTP-01 チャレンジのための Let's Encrypt 証明書要求フロー

次の図は、HTTP-01 チャレンジが使用される場合の Let's Encrypt® CA への証明書要求に関連するコンポーネントと手順を示しています。

証明書要求フローチャート

コンポーネント

図の鍵:

(A) 以前 kyr ファイルに保存されていたもの (B) 要求を確認するために必要なチャレンジ (D) Let's Encrypt CA などの ACME ベースの CA での認証に使用される ACME アカウントの資格情報 (C) 必要に応じて発信に必要なプロキシー・アカウント

フロー

CertMgr は ACME CA サーバーを使用してアカウント (C) を作成します
CertMgr は鍵ペアを作成し、CertStore (A) に書き込みます
CertMgr は CSR を作成し、ACME CA サーバーに送信します
CertMgr は受信したチャレンジ (B) を CertStore に保存します
ACME CA サーバーは、ドメインの所有権を確認するために、ポート 80 でチャレンジを要求します
Domino HTTP は、CertStore からのチャレンジ (B) で応答します
CertMgr は証明書チェーンを受け取り、CertStore (A) に書き込みます
HTTP (および INET タスク) は CertStore (A) から証明書と鍵を読み取ります

注:

certstore.nsf は、アクセスするすべてのサーバーに複製する必要があります。Let's Encrypt CA へのアクセスは、「ローカルまたは NRPC」ではなく、常に HTTP 経由で行われます。
Domino HTTP と CertMgr タスクは、CertStore を共有する別々の Domino サーバーで実行できます。
プロキシー通信はプロキシー・ユーザー (D) を使用します