リモートアクセス認証の設計 — SSHキー管理か証明書基盤か、ゼロトラスト入口かの判断

リモートアクセス認証の設計で問われる本質は、「誰が・いつ・どのホストに入れるか」を制御可能な状態に保てるかどうかです。静的SSHキーの配布はシンプルさの代わりに鍵の失効管理という負債を積み上げ、管理対象サーバーが50台を超える環境ではその管理コストが設計上の制約になります。証明書基盤への移行・HashiCorp Vault SSH・クラウドOS Loginの選定、あるいはゼロトラストアクセスとの組み合わせ——どの方式を採用するかは技術的な優劣ではなく、現在の環境規模・組織の運用体制・既存の認証基盤との相性で決まる設計判断です。本稿では、方式の選定基準と移行設計における落とし穴を整理します。

静的SSHキー配布の限界と証明書ベース認証が解決できる問題の整理

静的キー管理が積み上げる技術的負債

静的SSHキーの最大の問題は「信頼の証明ができない」点ではなく、「信頼の取り消しが即時にできない」点にあります。公開鍵を各サーバーの authorized_keys に配置する方式では、退職者や役割変更が発生したとき、対象の公開鍵がすべての接続先から確実に削除されたかどうかを検証する仕組みがありません。20台程度の環境では手動削除でも対処できますが、100台・複数リージョンに跨がる環境では削除漏れが構造的に発生します。

キー配布の仕組みがAnsibleやChef等のプロビジョニングツールに依存している場合、「どの公開鍵が現在どのサーバーに配布されているか」を一覧できる状態になっていることは少ないです。公開鍵の棚卸しを実施しようとして数十台のサーバーを横断するスクリプトを別途書く作業が発生した、という話は現場でよく聞きます。棚卸し自体が工数を要する設計になっている時点で、静的キー管理の限界が顕在化していると見るべきです。

証明書ベース認証が変える信頼の構造

SSH証明書は「公開鍵＋CA署名＋有効期間＋Principal（許可ユーザー／ホスト情報）」をひとまとめにしたトークンです。サーバー側に配置するのはCA公開鍵のみであり、個人ごとの公開鍵を管理する必要がなくなります。新入社員の追加も退職者の失効も、CA側の操作だけで完結します。

信頼の起点がCAに集約されることで、監査もCA操作のログを確認するだけで済みます。従来の authorized_keys 管理では「誰がいつ公開鍵を追加したか」という痕跡が残らないケースが多いですが、証明書方式では署名操作そのものがログとして記録されます。有効期間の設定によって「最大でいつまでアクセスを許容するか」を証明書単位で制御できる点も、静的キーにはない設計上の強みです。

移行を検討すべき環境規模の目安

経験則では、常時接続対象のサーバーが30台を超えてきた頃から鍵管理の手間が問題として顕在化しやすくなります。さらに複数チームが同一インフラを操作する環境、あるいはコントラクターや外部委託先が存在する環境では、台数に関わらず証明書方式の導入を検討すべき段階だと判断される傾向があります。

逆に、単一チームが管理する10台未満の環境でCA構築・運用コストを負うのは過剰投資になりやすいです。「今後2年以内に30台以上に拡張する計画があるか」「外部関係者がアクセスする可能性があるか」という2点が判断の出発点になります。どちらかに当てはまるなら、現時点での設計投資が後の移行コストを下げる判断になります。

OpenSSH CA vs HashiCorp Vault SSH vs クラウドOS Login — 選定比較

各方式が前提とするアーキテクチャの違い

OpenSSH CAは最もシンプルな選択肢です。CAキーペアを生成し、サーバー側にCA公開鍵を配置し、ユーザー証明書を発行する——それだけで証明書方式を実現できます。依存するサードパーティコンポーネントがなく、既存のSSHインフラにそのまま重ねられます。証明書発行・失効の管理フローをすべて自前で設計する必要があり、運用の複雑さはCAの規模に比例して増大します。

HashiCorp Vault SSHは証明書発行エンジンとしてVaultを使用し、証明書の有効期間や許可ユーザーの制御をポリシーとして定義できます。Vaultの認証バックエンド（OIDC、LDAP等）と統合できるため、既存のIdPと接続できる環境では有力な選択肢になります。クラウドOS Login（Google Cloud OS LoginやAWS EC2 Instance Connectなど）はクラウドプロバイダーのIAMと直接統合し、証明書管理をクラウド側に委ねられますが、マルチクラウドや自社データセンターへの適用が難しいです。

比較表による選定基準の整理

評価軸	OpenSSH CA（自前）	HashiCorp Vault SSH	クラウドOS Login
導入難易度	低〜中（手順は単純だが運用設計が必要）	中〜高（Vault自体の設計・運用が必要）	低（IAMと同一管理）
オンプレ対応	◎（制約なし）	◎（OSS版は自前ホスト可）	×（クラウドVM限定）
既存IdPとの統合	△（別途実装が必要）	◎（OIDC/LDAP等をサポート）	◎（クラウドIAM経由）
証明書有効期間の細粒度制御	○（発行スクリプトで制御）	◎（Vaultポリシーで定義）	△（プロバイダー依存）
運用継続コスト	低（CAの保護が主な運用）	中〜高（Vault可用性管理含む）	低（プロバイダーに委ねる）
マルチクラウド・オンプレ混在対応	◎	◎	△（プロバイダーごとに設計が異なる）

選定の決め手となるトレードオフ

Vault SSH を選ぶ最大の理由は「証明書発行の自動化とIdP統合を既存のVaultポリシー管理に統合できること」です。すでにVaultを利用している環境なら追加の運用コストが限定的になりますが、Vaultを新規導入するためだけにVault SSHを採用すると、Vault自体の可用性設計が主要課題になります。本来解決したかったSSH認証の問題より、Vault HA構成の設計・監視に工数を割くことになりかねません。

OpenSSH CAは「まず証明書方式の感覚をつかむ」「小規模な環境で最小コストで始める」場面に適しています。発行・失効・ローテーションの自動化はすべて自前実装になるため、スケールアップ時に設計の作り直しが必要になるケースがある点は事前に織り込んでおく必要があります。クラウドOS Loginは「クラウド環境に限定された用途でIAM管理を一本化したい」場合に選定の論拠が明確になります。

ゼロトラストアクセスを本番に適用するかの判断軸

ゼロトラストアクセスが前提とするネットワーク設計の変化

ゼロトラストアクセス（ZTA）の文脈でSSHを扱う場合、Cloudflare AccessやTailscaleといったソリューションが選択肢に挙がります。これらは「VPNで内部ネットワークに入れる状態にしてからSSH」という従来の前提を変え、「アクセス制御をネットワーク境界ではなくIDと端末状態で行う」構造に切り替えます。ネットワーク側の変更を伴うため、既存VPN基盤との並走期間が長くなるほどルーティングの複雑さが増します。

本番への段階的適用を計画する場合、まずステージング環境にのみZTAを適用し、VPNとの並走期間でトラブルを吸収してから本番に展開する順序で進めているチームが多いです。ステージング段階で接続パターンの網羅的なテストを行わないまま本番適用に踏み切ると、特定のサービス間通信やCIパイプラインの通信が通らなくなる問題が移行後に発覚するケースがあります。

ZTAを採用するかどうかの判断軸

ZTAが有効に機能する前提条件として「デバイス管理基盤（MDM）が整備されていること」「アクセス制御の起点となるIdPが存在すること」の2点が挙げられます。これらが整っていない状態でZTAのフロントエンドだけを導入しても、端末健全性の確認や証明書発行のフローが形骸化しやすいです。

リモートワーカーやコントラクターが本番環境の踏み台サーバーにアクセスする頻度が高い環境では、ZTAのIDベースアクセス制御が静的VPNより細粒度の制御を実現できます。「誰が・どの端末で・どのリソースに・何時にアクセスしたか」を記録する監査要件がある場合、ZTAのログ基盤はその要件を満たしやすいです。MDMとIdPが未整備の状態であれば、先にそちらの整備を優先させる判断が設計上の正解になります。

既存SSH基盤との共存期間の設計

ZTAへの完全移行が完了するまでの期間は、環境規模や関係者の数によりますが、50台以上の本番サーバーを持つ環境では3〜6ヶ月の並走期間を見込む設計が現実的です。並走期間中は「ZTA経由のアクセスを正とし、VPN経由のアクセスを段階的に絞り込む」という方向で進め、監査ログでZTA経由アクセスの比率が一定水準を超えたタイミングでVPN廃止を判断する段階管理が有効です。期間を定めずに並走させ続けると、二重管理が固定化するリスクがあります。

鍵のライフサイクル管理をどこまで自動化するか

証明書有効期間と自動ローテーションの設計

証明書の有効期間は「短すぎると運用コストになり、長すぎるとリスク管理の意味が薄れる」というトレードオフを持ちます。一般的な設計では、人間ユーザーの証明書は8〜24時間、サービスアカウントや自動化スクリプト向けの証明書は用途に応じて1〜7日程度が選ばれることが多いです。24時間以内の有効期間を設定する場合、証明書の再発行フローを完全に自動化しないと運用が立ち行かなくなります。

自動化の核になるのは「認証後の証明書発行を透過的に行えるか」という点です。ユーザーがSSH接続のたびに手動で証明書取得コマンドを実行しなければならない設計では、有効期間を短く設定しても現場で定着しません。SSH proxy commandやssh-agentの仕組みを利用して証明書の取得・更新をバックグラウンドで行える構成にすることが、自動化設計の目標になります。手を動かす実装については専門の技術セミナーや書籍で詳しく扱われているため、ここでは設計の方向性を示すに留めます。

CI/CDパイプラインとの統合判断

GitLab CIやGitHub Actionsなどのパイプラインから本番サーバーにSSHアクセスするケースでは、デプロイ用の認証情報をどのように発行・管理するかが設計課題になります。静的キーをCIのシークレットに保存するアプローチは手軽ですが、キーの失効管理がCI側の設定に依存するため、退役したCI環境のシークレットが残存するリスクがあります。

Vault SSHを使うアプローチでは、CI実行のたびに短命な証明書を発行する構成が実現できます。証明書の有効期間をジョブ実行時間に合わせて設定することで、万一証明書が漏洩しても被害を限定できます。Vaultとの通信経路の設計とネットワークポリシーの整備が前提になるため、CI側の変更だけで完結する話ではない点を設計段階で見込んでおく必要があります。

自動化しすぎない設計の境界

緊急時のアクセスや特権操作については、あえて手動の承認ステップを残す設計も有効です。フルオート化された証明書発行フローは利便性が高い反面、インシデント発生時に「誰が何の目的でアクセスしたか」の意図確認ができなくなります。特定のホストグループや操作クラスに対しては、証明書発行前に管理者の承認を求めるワークフローを設ける判断が求められる場面があります。自動化の範囲と承認を残す範囲を明示的に設計方針として文書化しておくことが、後から見直す際の判断根拠になります。

緊急アクセス手順を証明書方式でどう設計するか

Break-glass アクセスの設計原則

証明書方式に移行した環境でも、CA障害や認証基盤の停止時に本番サーバーにアクセスできる手段を維持しなければなりません。Break-glass（ガラスを割る）と呼ばれる緊急アクセス手順は、通常の認証フローを迂回する手段であるがゆえに、使用そのものが監査対象になる設計が求められます。

Break-glassアクセスの設計として現場でよく採用されるのは「オフラインCA証明書の物理保管」と「特定のメンテナンスユーザーアカウントへの静的キーを金庫等に保管する」パターンです。どちらの方式でも、緊急アクセスを使用した場合のアラート・ログ記録・事後レビューのフローを事前に設計しておく必要があります。手順を事後に整備しようとすると、インシデント収束後の疲弊した状態で後回しになりやすいです。

証明書失効と発行不能時のフォールバック設計

CAが停止した状態で有効期限切れの証明書しかない場合に備え、ホスト鍵と別に保管した静的バックアップキーを特定のメンテナンスユーザーに紐づけておくアプローチがあります。このバックアップキーは通常のデプロイフローには含まれず、金庫管理や秘密分散（Shamir’s Secret Sharing）で保護するケースもあります。

重要な設計判断は「バックアップキーへのアクセスをどの程度難しくするか」です。アクセスを容易にしすぎると証明書方式のメリットが失われ、難しくしすぎると本当に必要なインシデント時に利用できなくなります。「2人以上の承認が必要な手順」にするか「単一管理者が単独で使える手順」にするかは、組織の規模と深夜・休日のインシデント体制によって決まります。

緊急アクセスの事後処理フローの設計

緊急アクセスを使用した後のプロセスとして、使用したキー・証明書のローテーション、アクセスログの保全、インシデントレポートへの記録を定型化しておく必要があります。緊急アクセスの使用が監査ログにタグ付けされ、インシデントチケット登録が自動でトリガーされる設計が理想ですが、最低限「緊急アクセス使用＝即座にアラート送信」程度の仕組みは事前に用意しておく価値があります。使用後の追跡可能性が担保されていることが、緊急手順の設計として信頼を得る条件になります。

セッション記録と監査証跡をどの層で保持するか

ネットワーク層・ホスト層・プロキシ層の役割分担

セッション記録の取得層として選択肢が複数あり、それぞれ記録できる情報の範囲とオーバーヘッドが異なります。ネットワーク層（パケットキャプチャ）はSSHの暗号化通信を記録しても中身は見えないため、接続の有無と通信量しか分かりません。実質的に中身のあるセッション記録を取得するには、ホスト層またはプロキシ層での実装が必要です。

ホスト層での記録はauditdやosqueryで実現できます。各サーバーに個別に設定が必要になる分、管理対象サーバーが多い環境では設定漏れのリスクがあります。Ansible等での一括適用を前提とした設計にしないと、新規サーバーのプロビジョニング時に記録設定が漏れる問題が発生しやすいです。

踏み台サーバーでの集中記録の設計判断

踏み台サーバー（Bastion Host）を経由するアーキテクチャでは、踏み台でセッション記録を集中管理する設計が有効です。TeleportやBoundaryのようなPAM（Privileged Access Management）ソリューションはセッション記録機能を内包しており、すべての接続を踏み台に集約することで各サーバーへの個別設定なしにセッションログを取得できます。

踏み台を必ず経由させる設計は「踏み台が単一障害点になる」というトレードオフを持ちます。高可用性設計が必要になる点と、踏み台自体のセキュリティ保護が他のサーバーより厳格に求められる点を、設計段階で組み込む必要があります。踏み台の可用性がインフラ全体の接続可用性に直結するため、HA設計なしに踏み台集中記録を採用すると運用上のリスクが生まれます。

監査証跡の保持期間と改ざん防止設計

監査ログの保持期間は業界・コンプライアンス要件によって異なりますが、PCI DSS準拠が求められる環境では最低1年（うち3ヶ月はオンラインで即座に参照可能な状態）が基準になります。セッション録画はテキストログより容量が大きくなるため、長期保管にはオブジェクトストレージとの連携設計が求められます。

保管場所の設計で見落とされやすいのは「管理者がアクセスログを改ざん・削除できない構造になっているか」という点です。特権管理者が自分自身のアクセスログを削除できる環境では、監査証跡の信頼性が担保されません。Write Once（WORM）ポリシーや別アカウントへのログ転送でログの独立性を保つ設計が、コンプライアンス対応の根拠になります。

落とし穴 — 証明書方式への移行で詰まりやすい設計ミス

CAの単一障害点化と可用性設計の見落とし

証明書方式に移行した直後に顕在化しやすい問題が「CAが停止すると証明書発行ができず、有効期間切れのユーザーが全員ログインできなくなる」という障害です。有効期間を短く設定するほど、CAの可用性がインフラ全体の可用性に直結します。移行前は「CAが落ちても既存の証明書が有効な間は問題ない」と楽観視しがちですが、有効期間が8時間の設定では、CA障害から8時間以内に復旧しなければ誰もログインできない状態になります。

Vault SSHで構成する場合でも、Vaultクラスターのquorum障害が証明書発行の停止に直結します。Raftコンセンサスを使ったVault HA構成では3ノード以上で設計し、ノード喪失シナリオのrunbookを事前に整備しておくことが求められます。CAの可用性設計は「証明書方式を採用する前に決める事項」であって、移行後に気づく話ではありません。

静的キーとの混在期間の管理失敗

移行期間中に「古い静的キーも証明書も両方使える状態」が長期化するケースは多いです。移行完了前に静的キーを無効化しようとして業務影響が出ることを恐れ、移行期間が半年以上に及ぶ事例もあります。この期間が長いほど「どのユーザーが証明書方式に移行済みか」の管理が複雑化し、セキュリティ上の意義が薄れます。

対策として有効なのは「移行期限を先に設定し、期限後は authorized_keys を空にする」という強制的なカットオーバー計画を立てることです。authorized_keys の内容を定期的にスキャンして未移行エントリーを検出する仕組みを移行開始前に用意しておくと、進捗の可視化が容易になります。

証明書のPrincipal設計ミスによるアクセス制御の形骸化

SSH証明書のPrincipalは「この証明書で接続できるユーザー名」を制限する仕組みです。Principalの設計を誤ると、本来アクセスを限定したい証明書が任意のユーザー名でログイン可能になり、最小権限の原則が形骸化します。具体的な失敗パターンとして多いのは「全ユーザーにroot Principalを付与してしまう」「Principalを空にして制限なし状態になる」の2つです。証明書発行時のポリシーとして「発行するPrincipalはIdPのグループ情報に基づき自動設定する」という仕組みを設けず手動発行フローにしてしまうと、発行者の判断ミスでPrincipalの設定誤りが発生しやすくなります。

移行前に確認すべき設計チェックリスト

• 管理対象サーバーが30台以上か、または今後2年以内にそうなる見込みがあるか
• 複数チーム・外部関係者がSSHアクセスする環境であるか
• 退職者・ロール変更時の鍵失効を即時かつ網羅的に実施できているか
• authorized_keys の棚卸しを定期的かつ確実に実施できているか
• CAの高可用性設計（複数ノード・フェイルオーバー計画）を事前に策定できているか
• 証明書発行フローの自動化（ssh-agent統合など）を実装できるリソースと体制があるか
• Break-glass手順と緊急アクセスの事後フローを文書化できるか
• セッション記録・監査ログの改ざん防止設計（WORMポリシーや別アカウント転送）を組み込めるか
• 静的キーとの並走期間とカットオーバー日程を確定して関係者に合意できているか