Posted inSecurity

SSH Bastion Hostからの脱却：HashiCorp Boundaryでインフラアクセス管理をよりスマートに

Security tutorial - IT technology blog
Security tutorial - IT technology blog

「SSHキー管理」という名の悪夢

キャリアの初期、私は20人の開発チームのアクセス権限を設定するためだけに、午前中を丸々潰したことがありました。そのプロセスは極めて手作業に近いものでした。開発者からPublic Keyを送ってもらい、それをBastion Hostや各ターゲットサーバーの authorized_keys ファイルにコピー＆ペーストしていくのです。

人員の入れ替わりが激しくなると、状況は混乱し始めました。誰かが退職するということは、数十台のサーバーを一つずつチェックしてキーを削除しなければならないことを意味します。15台以上のサーバーで構成されるシステムのセキュリティ監査を行った際、私は衝撃的な数字を目の当たりにしました。退職したスタッフの古いキーの30%以上が、依然として残っていたのです。この時、Bastion Hostはもはや保護層ではなく、リスクの「温床」となっていました。秘密キーが一つ漏洩するだけで、インフラ全体がハッカーの前にさらけ出されてしまうのです。

なぜ従来のBastion Hostモデルは時代遅れなのか？

問題はSSHプロトコル自体にあるのではありません。問題はその管理方法にあります。SREがBastion Hostから離れつつあるのには、3つの致命的な弱点があります。

  • 曖昧なアイデンティティ： Bastion Hostはキーが一致するかどうかだけを気にします。実際にコマンドを打っているのが「誰」なのかは知りません。GoogleやOktaのような人事管理システム（IdP）とは完全に切り離されています。
  • 過剰な権限： 一度Bastionに侵入してしまえば、ユーザーは通常、内部ネットワーク全体を自由に動き回ることができます。これは「最小権限の原則（Least Privilege）」に反します。
  • 監査（Audit）の困難さ： 深夜2時に ubuntu ユーザーがデータベースを削除したログを見つけたとしても、20人の開発者のうち、その ubuntu は誰なのでしょうか？犯人を特定するには、通常、SSHログを丸一日かけて手動で調査する必要があります。

よくある代替案

Boundaryに出会う前、私はいくつかの応急処置的な方法を試しました。

  1. VPNの使用： この方法はより安全ですが、ネットワークレベル（レイヤー3）で権限を付与してしまいます。ユーザーがVPNに入ると、触れるべきではないサーバーまで「見えて」しまいます。
  2. SSH Certificate Authority (SSH CA)： 期限付きのキーを使用するため、プロフェッショナルな解決策です。しかし、独自のCAシステムを運用することは、小規模なチームやスタートアップには負担が大きすぎます。
  3. Identity-aware Proxy (Boundary)： これこそが「本命」です。IPやキーをチェックする代わりに、アイデンティティ（Identity）に基づいて認証を行います。「あなたが誰であるか」によって、自分に許可されたリソースだけが見えるようになります。

HashiCorp Boundary：キーレスなインフラアクセス

Boundaryを使用すると、IPを気にしたり複雑なキーファイルを管理したりすることなく、サーバーに接続できます。会社の管理アカウントでログインするだけで、Boundaryが必要なリソースへの一時的なセキュア接続を自動的に確立します。

ステップ1：Devモードでクイックスタート

最初から複雑な設定をする必要はありません。まずは dev モードを試して、5分でその仕組みを理解しましょう。マシンのメモリ内にデモ環境が自動的に構築されます。

# Ubuntuへのインストール
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install boundary

# Boundaryをdevモードで実行
boundary dev

このコマンドの後、ターミナルに Auth Method ID とパスワードが表示されます。ブラウザで http://127.0.0.1:9200 にアクセスし、管理画面の探索を開始しましょう。

ステップ2：TargetとHostの設定

Boundaryの構造は、Host Catalog -> Host Group -> Host -> Target という階層になっています。

実際の実装では、Workerのサブネット分割が非常に重要です。私はよく IP Subnet Calculator を使って、個別のネットワークゾーンのIP範囲を計算します。これにより、Workerがターゲットに正確に接続でき、Staging環境とProd環境間のIP競合を避けることができます。

以下は、コマンドラインでSSHターゲットを作成する方法です：

# プロジェクト用のスコープを作成
boundary scopes create -name "Project_Alpha" -scope-id "global"

# サーバーリストのカタログを作成
boundary host-catalogs create static -name "Backend_Pool" -scope-id "p_1234567890"

# 特定のサーバーを追加
boundary hosts create static -name "DB_Master" -address "10.0.1.50" -host-catalog-id "hc_1234567890"

ステップ3：「ワンタッチ」接続

ssh root@ip コマンドのことは忘れてください。Boundaryなら、コマンド一つで完了します。システムがローカルマシン上に中間プロキシを自動生成します。

boundary connect ssh -target-id t_1234567890

Boundaryは自動的にローカルポートを開き、ターゲットサーバーに直接マップします。TermiusやiTerm2といった使い慣れたツールもそのまま使用可能です。最大の利点は、すべてのセッションが記録される（Session Recording）ことです。何か問題が発生した場合は、「録画」を見直すだけで何が起きたかを確認できます。

実践的な運用のためのヒント

Boundaryのために複雑なYAMLファイルを構成する際、私はよく YAML ↔ JSON Converter を使って構文をチェックします。このツールは100%ブラウザ上で動作するため、非常に安全です。機密性の高いインフラ情報をサードパーティのサーバーに漏らす心配もありません。

システム用に重複しないトークンやIDを生成する必要がある場合は、 UUID Generator を覗いてみてください。Boundary内のリソースに割り当てるための標準的なUUID v4を素早く生成できます。

本番環境へのアドバイス

dev モードは学習用です。実際に本番環境で運用する場合は、以下の3つの原則に注意してください。

  • Controller의隔離： Controllerは最も安全なネットワークゾーンに配置してください。ターゲットサーバーと直接通信する必要があるのはWorkerだけです。
  • Root Keyの保護： Boundaryのルートキーの暗号化には、常にAWS KMSやHashiCorp Vaultを使用してください。
  • 即時のOIDC統合： ユーザーを手動で作成してはいけません。Google Workspaceなどと連携させましょう。社員が退職した際、メールアカウントをロックするだけで済みます。彼らのサーバーへのアクセス権限は、1秒以内にすべて消滅します。

「鍵を管理する」という考え方から「アイデンティティを認証する」という考え方への転換は、現代のDevOpsにとって死活問題です。それはシステムをより良く保護するだけでなく、SREチームを退屈な反復作業から解放してくれます。

Share:
Tags: