1つのVPNプロファイルを全員に配り、そこにあなたのパスワードが入っている
共有のApple VPNプロファイルは設定だけにとどめ、各自に固有の資格情報を渡します。受け渡しを分け、漏れたパスワードは発行元で交換してください。
プロファイルは問題なく入り、全員が接続し、やがてアカウントのパスワードがローテーションされる。ファイルを受け取ったすべての端末が同じ分に認証をやめるのは、どれも同じ秘密を抱えているからだ。これが兆候で、資格情報を一つの共有物にコピーすると、日常的なパスワード変更がフリート全体の停止に変わる。再利用できる構成と個人のアイデンティティを二つの別々の受け渡しとして保てばそれは避けられ、Apple自身のデバイス管理のドキュメントもプロファイルを設定と認可として扱い、秘密の保管場所とは見なしていない。
症状は最初のローテーションで現れる
mobileconfigファイルはXMLか署名済みplistである。コピーを持つ者は誰でもペイロードを復号して中身を読めるので、テンプレート内のAuthPassword値は、珍しい拡張子を持つ平文の資格情報である。署名が変えるのは完全性と出所であり、可読性ではない。一方、本当に共有したい部分、たとえばゲートウェイのアドレス、想定されるサーバーのアイデンティティ、トラフィックポリシーは全員で同じだ。
何かを編集する前に項目を仕分けよう、境界は人が思い込んでいる場所にはないからだ。
共有設定と個人の資格情報を分ける
| Item | Shared profile | Individual record |
|---|---|---|
| Gateway address, expected server identity | yes | no |
Traffic policy, IncludeAllNetworks, exclusions | yes | no |
| User password or account token | no | yes |
| Device identity or certificate | no | yes |
対話的な道は、パスワードを外に出し、対応する認証方式にそれを尋ねさせることだが、ここはよく読んでほしい。似ているだけの項目を消しても、対話ログインへの万能な変換にはならない。IKEv2ペイロードはAuthNameとAuthPasswordを区別し、認証方式がプロンプトに到達できるかどうかを決め;証明書ベースの方式はパスワードを一切尋ねない。
証明書にも共有鍵は要らない
ゲートウェイが証明書認証を想定しているなら、承認された仕組みで対象のユーザーまたはデバイスのアイデンティティを登録し、秘密鍵をテンプレートの外に置く。各コピーに一つの共有秘密鍵を入れると、より悪い影響範囲で同じローテーション問題を抱える、なぜなら鍵は人ごとに発行されていなければ人ごとに失効できないからだ。
そのアイデンティティの発行、更新、失効をプロファイルの改訂と並べて記録する。両方を一緒に追跡すれば、更新はインシデントではなく計画された作業になる。
無人マシンには第三の答えが要る
誰かがサインインする前に接続しなければならないマシンは、プロンプトに答えられない。これはサインイン済みの人にとって設定を簡単にすることとは別の要件であり、ゲートウェイの所有者と合意した管理されたアイデンティティかデバイスごとの証明書で解くべきで、プロファイルに人のパスワードを保存して解くものではない。
パスワードを保存しても二つ目の要素は消えない。ゲートウェイがMFAを要求するなら、パスワードを保存したプロファイルは起動時にも失敗し、その失敗は要素の欠落ではなく壊れたプロファイルに見える。
実際に生成された成果物を確認する
テンプレートは省略によって嘘をつく。管理サービスやエクスポートツールが完成ファイルに資格情報を注入することがあり、付随するアイデンティティのペイロードや診断用コピーがテンプレートに見えなかった材料を運ぶこともある。誰に渡してよいかを決める前に、生成された成果物を開く。信頼された発行元と想定されるサーバーアイデンティティの設定もそのまま保ち、パスワードを外すことはゲートウェイの信頼を弱める理由にはならない。
本物のパスワードや秘密のアイデンティティがすでに広がりすぎているなら、発行元で失効させて交換する。明日のテンプレートを編集しても、すでにインストールされたコピーには何の効果もなく、それらのコピーは背後の資格情報が取り消されるまで認証を続ける。
テスト用アイデンティティで受け渡しを受け入れる
別のテスト用アイデンティティとして登録した端末で承認済みの流れを使ってインストールし、想定された認証を完了し、トンネルが上がるのを見るだけでなく非公開リソースに到達する。プロファイルに資格情報の材料が含まれていないことを確認し、次にその資格情報が更新されるアイデンティティ記録に存在することを確認する。その組み合わせが受け入れテストだ。
共有設定のための改訂が一つ、人ごとの記録が一つ、そして実際に一度使った失効の道筋。