SSH から Teleport へ グリー株式会社 ネットワーク/インフラ/セキュリティエンジニア 吉浜 丈広

1. 自己紹介 2. Teleport とは 3. そもそもなぜ Teleport？ 4. Teleport を導入すると 5. 今後の話 はじめに 本日の内容 2

• 吉浜 丈広（よしはま たけひろ） • 2016 年にグリー株式会社へ新卒入社 • DC 内外のネットワーク管理・運用が主担当 • サーバ、ミドルウェアの検証・管理・運用 • ゲームや VR 配信のサーバサイド開発 • syslog, LDAP, Teleport 等の管理・運用、 インシデント時の対応 • ネットワーク/インフラ/セキュリティエンジニア はじめに 自己紹介 3

• Gravitational Inc. が提供しているアプリケーション • 複数のプロトコルに対応し、認証、監査ログの取得等の機能もある Proxy • 商用版とオープンソース版 Teleport とは ざっくり概要 画像出典：Gravitational, inc. gravitational/teleport. Github. https://github.com/gravitational/teleport 4

• Teleport には auth, proxy, node の 3 種類の役割がある • バイナリ自体は共通で設定で役割を決める • auth：認証を提供。proxy からアクセス可能な必要あり • proxy：全ての認証・ユーザ接続が経由。ユーザからアクセス可能な必要あり • node：SSH でのアクセス先。proxy からアクセス可能な必要あり Teleport とは ざっくり概要〜SSH代替の場合〜 利用者 proxy auth node1 node2 tsh ssh node2 認証 tunnel tunnel reverse ssh tunnle 5

そもそもなぜ Teleport ？ 既存環境の構成 データセンター 利用者 サービス1 サービス2 サービス3 管理用 LDAP Syslog 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 2 factor 各サービス用踏み台サーバ群 6

そもそもなぜ Teleport ？ 既存環境の構成 データセンター 利用者 サービス1 サービス2 サービス3 管理用 LDAP Syslog 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 2 factor 各サービス用踏み台サーバ群 踏み台サーバは約 140 台くらい サービス毎に異なる AWS アカウントで管理 アカウント毎に踏み台サーバが 1 つある 一度登録した鍵はずっと使える 一つの鍵でアクセス権のある全てのサーバへログイン可能 公開鍵は LDAP で管理 サーバへのアクセス権は Linux グループで管理 7 1 2 4 3

そもそもなぜ Teleport ？ 既存環境の構成〜利用者の場合（初回のみ）〜 データセンター 利用者 サービス1 サービス2 サービス3 管理用 LDAP Syslog 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 2 factor 各サービス用踏み台サーバ群 鍵の生成、アクセス権申請、 秘密鍵のダウンロード 公開鍵の登録、Linux グループへの追加 8 1 2

そもそもなぜ Teleport ？ 既存環境の構成〜利用者の場合〜 データセンター 利用者 サービス1 サービス2 サービス3 管理用 LDAP Syslog 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 2 factor 各サービス用踏み台サーバ群 認証 SSH 二要素認証 SSH 9 1 3 2 4

そもそもなぜ Teleport ？ 既存環境の構成〜利用者の場合〜 データセンター 利用者 サービス1 サービス2 サービス3 管理用 LDAP Syslog 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 2 factor 各サービス用踏み台サーバ群 認証 SSH 二要素認証 SSH 10 1 3 2 4

そもそもなぜ Teleport ？ 既存環境の構成〜管理者の場合〜 データセンター 利用者 サービス1 サービス2 サービス3 管理用 LDAP Syslog 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 2 factor 各サービス用踏み台サーバ群 監査ログ参照 各サーバは Syslog サーバへログを転送する 11

❌ 監査ログの利便性が低い • 踏み台から各サーバへは共通アカウントを利用 • 複数サーバに跨って sshd / sudo 等のログから辿る必要あり ❌ 鍵の管理が大変 • 公開鍵登録・権限申請用の自社アプリケーションを運用 • 秘密鍵がある端末からしかログインできない • 秘密鍵が漏洩した場合やクライアントが侵害された際のリスクが高い ❌ 利用者にとって不便な点 • 踏み台サーバへのアクセスはオフィスから or VPN 必須 • ログイン時の二要素認証めんどくさい、、、 • ログインサーバの FQDN なんだっけ、、、 そもそもなぜ Teleport ？ 既存環境の問題点 12

⭕ 監査ログの利便性が高い • teleport ではターミナルの入出力を全て記録・リプレイ可能 • teleport node/proxy で記録可能 ⭕ 鍵の管理が楽 • ユーザ認証時に毎回有効期限付きの秘密鍵を発行（ ssh-agent 自動登録） • 鍵に有効期限があるので漏洩時のリスク低減 • 商用版だと SAML 認証が使えるので既存 AD と連携した SSO で利用可能 ⭕ 利用者にとって便利な点 • 二要素認証不要 • WebSSH 機能により Web ブラウザから SSH 可能 • Web/cli クライアントからサーバ一覧可能 そもそもなぜ Teleport ？ Teleport の問題点に対するアプローチ 13

Teleport を導入すると 導入後の環境構成 データセンター 利用者 各サービス用踏み台サーバ群 サービス1 サービス2 サービス3 管理用 LDAP 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 Teleport auth/proxy cognito lambda 14

Teleport を導入すると 導入後の環境構成 データセンター 利用者 各サービス用踏み台サーバ群 サービス1 サービス2 サービス3 管理用 LDAP 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 Teleport auth/proxy cognito lambda Teleport の auth、proxy サーバを追加 踏み台サーバへ Teleport node を設定 踏み台サーバへ Teleport node を設定 cognito を追加し ID Provider として既存の AD を設定。 lambda を連携し、認証時に LDAP から Linux グループ情報 を取得し、アクセス権情報として利用 15 1 2 2 3

Teleport を導入すると 導入後の環境構成〜利用者の場合（初回ログイン時）〜 データセンター 利用者 各サービス用踏み台サーバ群 サービス1 サービス2 サービス3 管理用 LDAP 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 Teleport auth/proxy cognito lambda 認証、期限付き鍵生成 アクセス権情報取得 SAML 認証 16 1 2 3

Teleport を導入すると 導入後の環境構成〜利用者の場合〜 データセンター 利用者 各サービス用踏み台サーバ群 サービス1 サービス2 サービス3 管理用 LDAP 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 Teleport auth/proxy cognito lambda SSH アクセス reverse SSH tunnel SSH 17 1 1 2

Teleport を導入すると 導入後の環境構成〜利用者の場合〜 データセンター 利用者 各サービス用踏み台サーバ群 サービス1 サービス2 サービス3 管理用 LDAP 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 Teleport auth/proxy cognito lambda SSH アクセス reverse SSH tunnel SSH 18 2 1 1

Teleport を導入すると 導入後の環境構成〜管理者の場合〜 データセンター 利用者 各サービス用踏み台サーバ群 サービス1 サービス2 サービス3 管理用 LDAP 踏み台 鍵生成・登録 権限申請 システム 管理者 サーバ1 サーバ2 サーバ3 Teleport auth/proxy cognito lambda 監査ログ参照 19

Teleport を導入すると 利用者の例〜WebSSH〜 20

Teleport を導入すると 利用者の例〜tsh〜 21

Teleport を導入すると 管理者の例 22

• ターミナルの入出力記録により監査ログの利便性向上 • SSO でのサーバアクセスにより鍵の管理が不要に • 二要素認証やアクセス元 IP 制限が不要に • 鍵の有効期限があるためリスク低 • パブリックアクセスが必要なのは Teleport proxy のみのためリスク低 • 踏み台サーバへの Elastic IP が不要に • 既存の権限管理方法は変えず、管理者・利用者の利便性向上！ • Teleport auth/proxy サーバの運用というデメリットはあるが メリットの方が大きい Teleport を導入すると まとめ 23

今回のタイトルは SSH から Teleport へ つまり、完全移行 今後の話 そういえば 24

今回のタイトルは SSH から Teleport へ つまり、完全移行 出来てません😭 今後の話 そういえば 25

• tsh クライアントに対応していない • 開発時はコンソールだけでなくエディタや IDE で接続して利用もある • デプロイ等で利用するシステムアカウントの移行も要検証 • Teleport に障害が起きたらどうするの？ • cognito/lambda が死んだらどうするの？ • AD が死んだらどうするの？ 今後の話 課題はいろいろ残ってる 26

No content