共有CA、別々の扉：受け入れファイルごとに1つのサービス

共有認証局に対して検証される証明書が通ったのは信頼の試験であり、所属の試験ではありません。この二つの判断は、どちらも接続時に起きるために混同されがちで、その混同は、本来そこにいるべきでない人がサービスに入れられるまで見えません。解決策は第二の認証局ではなく、サービスごとに下され、デーモンが読む場所に記録される第二の判断です。二つを分けておけば、この分野の混乱の大半は消えます。

信頼された連鎖は、サービスの所属について何も語りません

二つのサービスが同じ発行階層を受け入れながら、異なる利用者集団を持つことはあります。一台のノートPCは前者に属し、後者に到達してはなりませんが、同じ階層の他のクライアントは本当にそこに属しています。そのサービスから認証局を外せば、正当に利用している全員を締め出すことになるので、作業は信頼ではなく受け入れです。

一つの扉に二つの錠を思い浮かべると分かりやすいでしょう。証明書が外側の錠を開け、サービスごとの判断が内側の錠を開けます；どちらも他方を代替しません。外側の錠だけのサービスは所属をまったく強制しておらず、単に認証しているだけです。動作する接続という形でしか存在しない方針は監査できないため、何かを変更する前に両方の判断を書き留めてください。以下は内側の錠について述べます。

任意の上書きを、受け入れの関門に変える

クライアント設定ディレクトリは通常は便利機能で、中のファイルはそれが名指すクライアントの設定を上書きし、ファイルのないクライアントはサーバーの既定値で動きます。一つのディレクティブがその便利機能を関門に変え、ファイルがなければ接続が拒否されるようにします。

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

コミュニティ版の OpenVPN 2.6 ccd-exclusive は、マニュアルページでまさにこの条件を記述しており、名前付きファイルの検索は有効なクライアント識別子に依存します。他のビルドや製品管理のサーバーでは異なる場合があるため、他所で同じ意味論に頼る前にインストール済みのバージョンを確認してください。

上のパスはあくまで例として扱い、手引きが考案したディレクトリを作るのではなく、実際に配備された配置を確認してください。この断片は条件を追加するだけで何も取り除きませんから、既存の証明書検査、サーバー識別子の検査、アカウント認証はそのままにしてください。誤った箇所で上げた拒否は証明書の故障に見え、調査を認証局の方向へ向けてしまうため、本番前に変更を準備してください。その後、拒否されたクライアントのログ行が連鎖ではなく欠けている設定ファイルを名指すことを確認してください。

サービスごとにひとつのディレクトリ、ひとつの共有リストではない

所属はそれを強制するサービスに属するので、各サービスは自分のディレクトリと自分のファイルを持ちます。二つのサービスを一つのリストに向けると、所属を共有することになる誰が意図したかに関わらず、その結果の変更を判断までたどるのは困難です。共有認証局は共有のままでかまいませんが、受け入れファイルはそうはいきません。分けておけば、あるサービスの誤りが別のサービスを静かに広げることもありません。

DEFAULT エントリは人を誤解させるケースです。名前付きファイルが見つからないときの代替設定を提供しますが、関門が要求する名前付きファイルではないため、単独でクライアントを受け入れることはできません。エントリがまったくないクライアントを試して拒否を確認してください；そのクライアントが受け入れられるなら、代替が適用されており、ccd-exclusive そのインスタンスでは有効ではありません。

有効な識別子が、どのファイルを読むかを決める

検索には、クライアントが実際に認証した識別子、通常は証明書のコモンネームが使われます。サーバーがユーザー名とパスワードも検証し、その名前をコモンネームにマップする場合、ファイルは認証されたユーザー名に一致しなければなりません。不一致があると、決して選ばれないもっともらしいファイル名でディレクトリが埋まったままになります。

読み取りがもう半分です。デーモンは通常、起動後に特権を手放すため、権限を落としたアカウントにディレクトリとその各エントリへの読み取りアクセスが必要です。セルフサービス受け入れは仕組みを完全に無効にするため、クライアントが書き込み可能な経路から自分のエントリを作れるようにしてはいけません。あるアカウントには閉じて見えるディレクトリが別のアカウントには開いていることがあるため、ファイルモードだけでなく、マウントと共有の権限も確認してください。次に、unit ファイルが挙げているアカウントではなく、実行中のプロセスが実際に使っているアカウントを確認してください。両者が同じなのは、他に何も変えていないときだけです。

拒否、受け入れ、失効を別々に観察する

サービスに属する識別子を試し、接続できることを確認します。エントリのない有効な証明書を試し、拒否されることを確認します。別のサービスに受け入れられた識別子を試し、ここでは受け入れられないことを確認します。その文脈のない結果は他の誰も再現できないため、各結果のそばにサービスインスタンスと有効な識別子を記録してください。

取り消しは失効とは別の操作です。受け入れファイルを編集するとひとつのサービスの権利が外れ、識別子は他のどこでも有効なままですが、侵害された鍵には組織の失効対応が必要です。ディレクトリの編集も失効リストもそれ自体ではセッションを終わらせないため、すでに確立したセッションをどうするかを前もって決めてください。

受け入れは最初の関門にすぎません。サービスに加わったことは、その背後のサブネット、データベース、管理インターフェースについて何も語らず、そのリソース方針は別に書いて試す必要があります。