VPN ユーザーを登録する：まず ID の所有者を特定する

誰かが VPN へのアクセスを求め、最初の反応はサーバーで adduser を実行することです。その反応が正しいのは、限られた一部の配備だけです。何かを作る前に、アカウントが製品のデータベース、ID プロバイダー、あるいはホスト自身の認証スタックに存在しうることを踏まえ、サーバーの構成を開いて、そこにどの製品が動いているのか、どこで資格情報を検証しているのかを確認してください。誤った種類のアカウントを作ると、その人はログインはできるのにトンネルが使えない状態になります。

OpenVPN と書かれたクライアントプロファイルが示すのはプロトコルであり、その背後にある ID システムではありません。

adduser ではなくサーバーから始める

まず製品を特定します。Community OpenVPN はデーモンと、そこに組み込んだ認証の組み合わせであり、Access Server は独自のユーザー層を持つ製品です。構成、ユニット名、パッケージ一覧を確認し、ユーザー管理用の Web インターフェースがあるかを調べます。次に、配備されたプロファイルが、証明書、ユーザー名とパスワード、あるいはその両方のどれでクライアントに身元を証明させるかを確認します。その答えが、アカウントを所有するシステムを名指しします。

その後に初めて、ユーザーを作成するという言葉に意味が出ます。証明書だけの配備では、承認された手順でデバイスの ID を発行することを意味し、Unix ログインは何も変えません。パスワードによる配備では、実際にパスワードを検証するバックエンドを意味します。

四つのバックエンド、アカウントを作る四つの場所

Access Server のローカル認証はアカウントを自前のデータベースに保持するため、それを作るインターフェースはホストではなく製品に属します。PAM は検証をオペレーティングシステムのスタックに委ねるため、サービスがそのスタックを選んだ場合にはローカルの Unix アカウントが登録の一部になり得ます。LDAP、RADIUS、SAML は検証を外部サービスへ移し、プロビジョニング、パスワードポリシー、MFA はそこに置かれます。Access Server は四つのケースすべてでユーザーごとの証明書と権限を保持でき、それが分離を分かりにくくしています。

グローバルな既定値ではなく、この特定ユーザーに有効な方式を確認します。Access Server 2.10 以降はグループ単位やユーザー単位で異なる認証方式を適用できるため、既定値がローカルであることは、目の前のアカウントがローカルで検証される証明になりません。

権限は別の判断である

認証はその人が誰であるかに答え、権限はその人が何に到達できるかに答えます。成功したログインは付与ではないため、この二つを二つの手順として保ちます。意図した経路、リソースの許可、管理権限を意識的に割り当て、無関係なアクセスは拒否されたままであることを確認します。配備が個人ごとの ID を支える場合は、共有プロファイルを一人のために失効させることはできないため、他人のプロファイルを転送するのではなく一人につき一つを発行します。

クライアント側の素材も重要です。自動ログインのプロファイルと対話的なユーザーログインは異なる認証関係を表し、一方を他方に置き換えるとサーバーが実際に検証する内容が変わります。

アクセスの失効は登録の一部である

ユーザーを作る間に、誰がアカウントを検証するのか、誰が VPN アクセスを承認するのか、どの機器またはプロファイルが接続を表すのかという三人の所有者を書き留めます。それらは三つの異なるシステムになり得て、そのうち一つだけを挙げる失効計画は経路を開いたままにします。その人が去るときは、権限をその所有者から外し、発行したすべての資格情報をその所有者のもとで失効させます。ダウンロードしたファイルを削除することは失効ではなく、外部の ID がまだ認証されているならローカル項目の削除も失効ではありません。

次に、攻撃者がするように、新しい ID で一度接続して意図したリソースへのアクセスを確認し、無関係なリソースが依然として拒否することを確認して登録を試します。最初の接続が成功し、かつ否定的なテストも通れば、登録は完了です。

記録はそれが属するプロファイルと一緒に保管します。次の監査担当者は、ある月に誰が接続できたかを尋ねるので、その答えはこの三人の所有者の中にあります。