【ITニュース解説】Forced SSH commands still need a complete key policy

システムエンジニアを目指す上で、サーバーへの安全なアクセスは非常に重要な知識となる。特にSSH（Secure Shell）という技術は、リモートのコンピューターに安全に接続するための標準的な方法であり、その使い方とセキュリティ対策について深く理解しておく必要がある。この記事は、SSHの公開鍵認証で「強制コマンド（Forced SSH commands）」という特定の機能を利用する際に、単に設定するだけでなく、どのようなセキュリティ上の考慮が必要か、そしてなぜそれが重要なのかを解説している。

まず、SSHの公開鍵認証では、サーバー側のauthorized_keysというファイルにクライアントの公開鍵を登録することで、パスワードなしで安全に接続できるようになる。このauthorized_keysファイルには、単に公開鍵を登録するだけでなく、その鍵が認証されたときに実行できる操作に様々な制限を加えることができる。「強制コマンド」とは、この制限機能の一つで、特定の公開鍵を使って接続してきたユーザーに対して、あらかじめ指定した特定のコマンドだけを実行させ、それ以外の操作を一切許可しないように設定できるものだ。これは、例えばサーバーのバックアップを自動で実行するエージェントや、プログラムの自動デプロイツールなど、特定の目的に限定されたアクセスが必要な場合に非常に有用だ。また、端末の割り当てを無効にしたり、ポート転送などの機能をオフにしたりすることもできるため、不正なアクセスがあった場合の被害を最小限に抑える効果も期待できる。

しかし、記事では「強制コマンド」を設定しただけでは、完全な認証システムとしては不十分であると指摘している。なぜなら、実際にその鍵が何を実行できるかは、設定したコマンドだけでなく、鍵の所有者、サーバーの環境設定、そしてサーバー自体の設定など、多くの要素によって決まるからだ。

OpenSSHには、restrictという便利なオプションがあり、これを使うと、対話型シェルや各種転送機能をまとめて無効にできる。これはセキュリティを強化するための良い出発点となる。そして、command=オプションを使って、実際に実行させるコマンドを明示的に指定する。もし、クライアントからのリクエスト内容を強制コマンドに渡して処理させる必要がある場合は、SSH_ORIGINAL_COMMANDという環境変数を通じてその内容を受け取ることができる。しかし、このSSH_ORIGINAL_COMMANDも、クライアントから送られてくる「信頼できない入力」として扱い、プログラム内で厳格に検証する必要がある。これを安易にシェルに渡してしまうと、予期せぬコマンドが実行されたり、脆弱性が生じたりする危険性があるため、細心の注意が必要だ。

次に、公開鍵の扱い方についてだ。公開鍵は、あくまで「認証要素」であり、その鍵を使える人がサーバー上でどのような「役割」や「権限」を持つかを示すものではない。そのため、authorized_keysファイルには、どの鍵が誰のものなのか、そして何のために使われるのかをコメントで明確に記述することが推奨される。さらに、異なる目的や異なる権限レベルでの操作が必要な場合は、同じ鍵を使い回すのではなく、それぞれ専用のUnixアカウントやサービス用のアカウントを作成し、それぞれに専用の鍵を割り当てるべきだ。例えば、ファイルパスへのアクセス権限が異なる二つのシステム統合を行う際に、見た目が似たようなコマンドを使うからといって、一つの鍵を共有させてしまうのは危険である。また、強制コマンドの設定は、サーバー全体のSSH設定ファイルであるsshd_config内のForceCommandなどの設定によって上書きされる可能性があるため、鍵を追加する際にその行だけを見るのではなく、サーバー全体の有効な設定を確認し、意図した通りの挙動になるかを検証することが重要となる。

そして、強制コマンドとして実行されるプログラムのセキュリティも非常に重要だ。固定コマンドとして指定するプログラムは、絶対パスで指定された信頼できるバイナリであるべきだ。また、そのプログラムが実行される作業ディレクトリから、攻撃者によって制御されうる設定ファイルを読み込まないように注意する必要がある。作業ディレクトリを厳密に制御し、セキュリティリスクとなりうる環境変数はクリアするか、安全な値に置き換える。ログインシェルが読み込む設定ファイル（プロファイル）に依存しないようにすることも大切だ。もし、その強制コマンドがさらに別のプロセスを起動する場合、その子プロセスに対しても同様のセキュリティルールが適用されるべきだ。外部からパラメータを受け入れるプログラムの場合、シェル文字列をそのままパースするのではなく、厳密な文法に基づいて解析し、許可されたサブコマンドや検証済みの値のみを受け入れるようにする。改行文字、シェルにおける特殊文字（メタ文字）、パス横断攻撃につながるようなパス指定、予期せぬオプションなどは拒否し、エラーメッセージを返す際も、秘密情報やコマンドライン全体を漏らさないように注意する。

設定が完了したら、その制限が本当に機能しているかを徹底的にテストすることが不可欠だ。実際にその鍵を使ってサーバーに接続し、意図したコマンドが正しく実行され、オプションが期待通りに動作するかを確認する。さらに重要なのは、設定したポリシーが「防ぐはずのこと」が本当に防がれているかを積極的に試すことだ。具体的には、対話型シェルの要求、エージェント転送やポート転送の試行、X11転送の要求、疑似端末の要求、そして強制コマンドのラッパーが拒否するはずの不正なコマンド文字列の送信、統合対象のディレクトリ外へのアクセスなどを試みる。OpenSSHのバージョンアップや、アカウントのグループ設定変更があった後には、必ずこれらのテストを繰り返す必要がある。なぜなら、鍵のオプションやサーバーの設定は、ソフトウェアのバージョンや環境によって挙動が変わる可能性があり、開発環境で問題なかった設定が本番環境で異なる動作をする場合があるからだ。

最後に、鍵のライフサイクル管理と、その利用に関する証拠（ログ）の保持も非常に重要となる。それぞれの鍵に対して、所有者、使用目的、作成日、有効期限（またはレビュー日）、そしてその鍵でアクセスできるシステムを明確に関連付けて管理する。そして、その鍵が必要なくなった統合が終了した際には、速やかにその鍵を削除する。セキュリティリスクのレベルに応じた適切なスケジュールで鍵を更新（ローテーション）し、もし鍵が漏洩した可能性や侵害が疑われる場合は、直ちにその鍵を無効化し、新しい鍵に交換する必要がある。単に新しい鍵を追加して古い鍵をそのまま放置するのは非常に危険だ。認証の試行、強制コマンドの実行、認証の失敗など、SSHに関する一連の操作は適切にログに記録するべきだが、秘密鍵の情報や機密情報そのものをログに残してはいけない。予期せぬ送信元からのアクセスや、繰り返し試みられる不正なコマンドに対しては、速やかにアラートを出すような仕組みを構築する。これらのログには、その鍵が意図された操作のために、期待されるホストから、期待される時間に利用されたかどうかを後から検証できるだけの十分な情報を含める必要がある。

SSH鍵の真の強力さは、単なるテキストの文字列にあるのではなく、それを受け入れるアカウントの設定、実行されるコマンドのパス、実行環境、そしてサーバー全体に適用されるセキュリティポリシーが、全て一体となって作り出す「完全な境界」にある。強制コマンドは、これらの要素が全て適切に管理され、連携して機能している場合に初めて、健全で効果的なセキュリティ制御となる。テストもライフサイクル管理も行われず、ただ漫然とauthorized_keysファイルに一行コピーされただけの設定は、単なる「こうなると良いな」という希望的な制限に過ぎず、実際のセキュリティにはほとんど貢献しないことを理解しておく必要がある。