iPad に専用の VPN クライアント証明書は必要か？

新しい iPad がチームに加わるとき、最短の方法は既存のクライアント証明書を書き出してタブレットにインストールすることです。それは誰かが退職したり、端末を紛失したり、どの端末がいつ接続したかを示す監査を求められるまで機能します。判断すべきは証明書ファイルではなく、各端末を個別に認可し失効できるかという ID です。コストと管理の手間が答えを決めますが、どちらも見た目より小さいものです。

共通の発行者、別々の ID

どの端末も同じ認証局を信頼し、同じゲートウェイに接続しながら、異なるクライアント ID を持つことができます。発行者は信頼のアンカーであり、ID は鍵ペアで、そのサブジェクトをサーバーがポリシーに対応付けます。この二つを混同すると、共有証明書が無害に感じられます。無害でいられるのは、どの端末がセッションを開いたかを誰かが知る必要が生じるまでです。

発行者を共有すると設定作業が減り、端末ごとの説明責任は何も変わりません。ID を共有すると、すべての端末が一つの失効単位に押し込められ、一つを失効させれば全部が失効し、代替を認可すればこれまで作られた鍵のコピーすべてが認可されます。この交換は、金曜の午後に速いからという理由でファイルをコピーするのではなく、明示的に行う価値があります。

二つ目の証明書が高くつくとき

端末ごとの登録には、管理されたペイロード、SCEP リクエスト、またはワンタイムパスワードを使った誘導付きインポートという一手間がかかります。シリアル番号と有効期限を追跡する場所も必要で、これは最初の証明書が切れるまでほとんどの配備が忘れている部分です。どちらのコストも一度きりで、登録フローが自動化すればどちらも小さくなります。

タブレット二台と利用者一人の家庭では、共有 ID は一行で文書化できる妥当な判断であり、コストは現実的です。しかし、人ごとまたは端末ごとにアクセスを取り消す必要があるサービスでは、失効の筋書きこそがパスワードではなく証明書を使う理由そのものだから、妥当ではありません。配備は、今日いくつ端末があるかではなく、端末がどれくらい頻繁に持ち主を変えるかで評価してください。

端末を登録し、鍵をコピーしない

現代のプラットフォームは秘密鍵を保護された保管庫に置き、設計上エクスポート不可と印を付けるものもあります。その性質がそもそもコピーを不可能にし、ノート PC から書き出したバンドルをサポートされた方法でタブレットに再インポートできない理由でもあります。それでも試すと、きれいにインストールされ、その後決して認証しないプロファイルができます。

配備がすでにサポートしている登録方法、つまり管理された ID ペイロード、SCEP サービス、または端末上で新しい鍵を発行するアカウントベースのフローを使ってください。欠けた ID を埋めるために認証局の秘密鍵を配るのは、影響範囲がはるかに大きい別の誤りです。認証局は資格情報を発行するものであり、エンドポイントへ渡ってはいけません。

答える前に失効を確認する

共有の選択肢を選ぶ前に、最悪の日に失効がどう見えるかを書き出してください。答えが複数の端末に影響する一つの操作なら、その設計はすでにあなたに不利な判断をしています。

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

実際に手元にある素材、つまり秘密鍵が存在するか、サブジェクトが何を述べているか、シリアルを個別に失効できるかを確認してください。鍵のない証明書ファイルは何も認証できない、これがコピーした ID の一部が最初の接続で失敗する理由です。

タブレットからアプリを削除しても失効にはならず、誰かが無効化するまでサーバーは ID を受け入れ続けます。最初の端末を登録する前に、その一文を手順書に書いてください。