Posted inセキュリティ

Teleportによるアクセス制御の集約：SSH、Kubernetes、データベースセキュリティのガイド

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

鍵管理の悪夢から解放されるインフラ運用

5台のサーバーのSSHキーを管理するのは簡単です。しかし、50台になり、さらにKubernetesクラスターや本番環境のデータベースが加わると、管理は破綻します。私がシステム管理者になった最初の1ヶ月、数ヶ月前に退職したユーザーを削除するためだけに、authorized_keys ファイルの監査に20時間近く費やしました。これは単に面倒なだけでなく、重大なセキュリティ上の脆弱性でした。

Teleportは、恒久的なキーを短命の証明書に置き換えることで、この問題を解決します。これを「統合アクセスプレーン」と考えてください。スタック全体に対する安全な玄関口として機能し、すべてのセッションに多要素認証（MFA）を要求し、「いつ、誰が, 何をしたか」という明確な監査証跡を提供します。

クイックスタート：5分でTeleportを稼働させる

まずは、単一のLinuxノードにTeleportをインストールします。このインスタンスが、Auth Service（認証局）、Proxy（ゲートウェイ）、SSH Node（ターゲット）のすべてを処理します。

1. Teleportバイナリのインストール

Teleportは、ほとんどの主要なLinuxディストリビューションをサポートしています。UbuntuまたはDebianを使用している場合は、以下のコマンドを使用して公式リポジトリから取得します：

sudo curl https://apt.releases.teleport.dev/gpg \
  -o /usr/share/keyrings/teleport-archive-keyring.asc

source /etc/os-release
echo "deb [signed-by=/usr/share/keyrings/teleport-archive-keyring.asc] \
  https://apt.releases.teleport.dev/${ID?} ${VERSION_CODENAME?} stable/v15" \
  | sudo tee /etc/apt/sources.list.d/teleport.list > /dev/null

sudo apt update
sudo apt install teleport

2. 設定ファイルの生成

Teleportの動作を定義するために、有効な設定ファイルが必要です。サーバーを指すドメイン名がある場合は、Let’s Encryptを使用してSSL設定を自動化できます。

# teleport.example.com を自身のドメインまたはパブリックIPに置き換えてください
sudo teleport configure --acme [email protected] --cluster-name=teleport.example.com > /etc/teleport.yaml

3. サービスの起動

次に、再起動後も自動的に開始されるよう、デーモンを有効化します。

sudo systemctl enable teleport
sudo systemctl start teleport

4. 管理者ユーザーの作成

最後に、最初のアカウントを作成します。このコマンドは、1時間で期限切れになる1回限りの登録リンクを生成します。

sudo tctl users add admin --roles=editor,access --logins=root,ubuntu,ec2-user

ブラウザでそのリンクを開き、MFA（YubiKeyやGoogle Authenticatorを推奨）を設定します。マスターパスワードについては、toolcraft.app/ja/tools/security/password-generator にあるブラウザベースのジェネレーターを使用することをお勧めします。高速で、ブラウザ内でローカルに動作し、弱い資格情報でセットアップを開始してしまうのを防げます。

アーキテクチャの転換：キーから証明書へ

Teleportは単なるSSHのラッパーではありません。アクセス権限の付与方法を根本から再考したものです。従来のセットアップでは、ノートパソコンが盗まれた場合、手動で特定して無効化するまで秘密鍵は有効なままです。これはセキュリティ上の大きなリスクです。

短命の証明書の仕組み

Teleportでは、tsh login を実行してMFAで認証します。すると、Auth Serviceから、例えば8時間で期限切れになる証明書が渡されます。サーバーに接続する際、ノードはその証明書を信頼されたCA（認証局）と照合して検証します。8時間が経過すると、証明書は無効になります。クリーンアップも、放置されたキーも、手動の無効化作業も必要ありません。

3つの主要構成要素

  • Auth Service: 頭脳です。認証局（CA）を管理し、アクセス権限のポリシーを適用します。
  • Proxy Service: 門番です。すべての着信トラフィックを処理します。Proxyが内部ノードへのセッションをトンネリングするため、サーバーをパブリックインターネットに公開する必要はありません。
  • Node Service: エージェントです。ターゲット（サーバー、K8s、DB）上で動作し、Proxyへの安全なアウトバウンド接続を維持します。

プロトコルの認識

Teleportは、そこを通過するトラフィックを実際に理解します。SSHの場合、ターミナルの出力を映画のように記録します。Kubernetesの場合、kubectl コマンドをログに記録します。データベースの場合、生のSQLクエリをログに記録します。これは、標準的なSSHトンネルでは提供できない深い可視性です。

共有資格情報なしでデータベースを保護する

データベースアクセスは、Teleportの最高の機能の一つです。データベースのユーザー名やパスワードを渡すことなく、開発者に本番環境のPostgreSQLインスタンスへのアクセスを許可できます。すべては証明書経由で処理されます。

1. データベースをTeleportに追加する

データベースが存在するサーバー（またはゲートウェイノード）の teleport.yaml を更新します：

db_service:
  enabled: "yes"
  databases:
    - name: "prod-db"
      description: "本番環境メインPostgreSQL"
      protocol: "postgres"
      uri: "localhost:5432"

変更を適用するためにサービスを再起動します。その後、データベース側でTeleportのCAを認証用として信頼するように設定します。

2. CLI経由でデータベースにアクセスする

ローカルターミナルからのワークフローはシームレスです：

tsh login --proxy=teleport.example.com
tsh db login prod-db

# 標準のローカルツールを使用して接続
tsh db connect prod-db

Teleportはローカルプロキシを立ち上げ、バックグラウンドで証明書を処理し、通常通り psql を使用できるようにします。その間、実行したすべてのクエリはコンプライアンスのためにログに記録されます。

本番運用のためのプロのヒント

Teleportをしばらく運用した後、これら3つの習慣を身につけると、多くのトラブルを回避できます。

リプレイを確認する： Web UIは単なる見せかけではありません。午前3時に設定ファイルが壊れた場合、最後にログインした人のセッション録画を確認できます。推測に頼らず、何が問題だったのかを正確に把握する最速の方法です。

ラベルで整理する： ホスト名だけでノードをリストしないでください。env: production や team: devops といったラベルを使用します。これにより、「バックエンド開発者は、環境（env）が本番（production）以外のノードにのみアクセスできる」といったスマートなRBACルールを作成できます。

アップデートを継続する： Teleportの進化は速いです。数ヶ月ごとに主要なセキュリティ更新と機能アップデートが提供されます。私は通常、安定性を確保しつつパッチを適用するために、最新バージョンから1つマイナーバージョン戻ったもの（例：v15.2が出た時にv15.1を使用）を使用するようにしています。

Teleportへの切り替えは、セキュリティを「ネットワークを信頼する」から「アイデンティティを信頼する」へと変革させます。基本的なSSHキーよりも設定に数分長くかかりますが、誰がインフラを操作しているかを正確に把握できる安心感は、その労力に見合う価値があります。

Share:
Tags: