SSH やめました その2

この記事は弁護士ドットコムにおいて SSH やめました その1 の続きです。前置き無しに書いちゃいます。

3. ファイルの転送

サービスに必要なものは Gitlab で管理されているし、当社では前述の通りコンテナ化が進んでいるため設定ファイルなんかも含んだ形でイメージが作られてコンテナレジストリに登録されているし、設定に必要な値は環境変数で注入されるし、基本的にサーバーにしか無いファイルや後からファイルを転送しなければならないということは無いはずなので、 scp などする必要はないはずです。

以上、終了、といきたいところですがなにごとにも例外があります。詳細についてここで書くことができませんが、ファイル転送を必要とするプロジェクトやプロダクトに対し、ファイルの中継用の S3 バケットを用意しています。

4. Git 操作

先述の通り、当社ではソースコード管理に Gitlab を使用しています。先日 Omnibus 版に移行したことを書いてもらったので、もし興味があったらそちらもご覧ください。

Git への操作というと、標準的には SSH 接続と HTTPS 接続のふたつがあると思います。 AWS 上でサービスを作っていると ELB(Elastic Load Balancer) を利用することが多いと思いますが、当社では GItlab の運用も歴史が長いこともあり、 SSH を通すためにも CLB(Classic Load Balancer) を使っていました。各種ユーザー向けサービスの環境への SSH 接続をなくしていく中で、 Git 操作のみに SSH を使うというのもどうかと思い、 HTTPS の接続に変えることにしました。これにより、 ALB (Application Load Balancer) を使えるようになり WAF (Web Application Firewall) が利用できるようになりました。いざ WAF を入れてそのログを見てみると、多くの余計なアクセスがあることがわかってギョッとします。

ちなみに、 Git 操作において SSH をやめて HTTPS を使うようにするというのは、実際にコードを書いているエンジニアやデザイナーの協力無くしてできません。 HTTPS に移行するために、可能な場合は既存のローカルリポジトリは削除して HTTPS で git pull し直してもらう方法や、既存のローカルリポジトリのリモートを変更する git remote set-url origin https://xxxx という方法などについてのドキュメントを書き、説明会やハンズオンの会を開いたりしました。また、社内に多くある開発環境の構築手順から SSH に関する記述をこまめに書き換えていくなどという作業も行いました。

5. サービスのデプロイ

サーバーを使ってサービス開発をしていた頃、初期にはサーバーにリモートログインしてなんらかのデプロイ操作をすることはあったと思います。現在当社で提供しているサービスでは CodeDeploy や ECS などが使われていますが、最後まで残った SSH 系のデプロイに Capistrano を使ったものや Git 操作を Slack 経由で行うものがありました。

ユーザー向けのサービスについてはコンテナ化やマネージドの WordPress への移行などにより、自然と Capistrano の利用箇所が消滅しました。また、社内向けのサービスではコードレビューのランダムアサインを行う仕組みが Slack 経由の Git 操作で動いていましたが、別の仕組みを設けてもらったことで不要となり、無事退役を迎えました。

6. ansible による各種操作

ansible とはシステム構築や運用を自動化するためのソフトウェアで、こちらの利用は SRE メンバーに限られます。なお、コンテナ化をはじめとするインフラ構成の変更や SSM の利用が進んだことで、 ansible 自体の利用箇所は大きく減りました。

現在も ansible を使っている箇所では、 その1 で触れた SSM を使って実行するようにしています。 SSH では ProxyCommand という命令が使えるため、ここで SSM を使うという方法です。 .ssh/config に記述する方法が AWS のドキュメントに書かれています。こちらについても SSH をやめるというタイトルからするとズコーッという感じでしょうか。

おわりに

ということで、今回は SSH をやめた話を2記事に渡って書きました。 SSH は便利だし、ちゃんと使ってちゃんと運用されていたら良いことづくめなのですが、その陰には不安感があるのも事実です。 SSH をやめられたことで、 bastion の運用やサーバーごとのユーザー管理からは解放され、危険度もいくらかは軽減できたと思うので良かったと思います。

この記事が気に入ったらサポートをしてみませんか?