コード漏洩時のリスクを軽減しつつ、ユーザー管理しやすくする　LightsailからEC2への移行、AWS SSOの採用

自己紹介

菊池宣明氏（以下、菊池）：菊池宣明と申します。本日はよろしくお願いします。はじめに、簡単に自己紹介をさせてください。最近私は主にSRE関係の仕事を担当しています。2022年から「ハッカー飯」の開発者メンバーとしてジョインしました。経歴を簡単に述べると、科学系の大学院を卒業して、その後とあるCIerの会社に新卒で入社しました。

ここでは主にAWSについて業務でたくさん取り組み、そこでしばらく修行を積んだ後に、2021年の夏ごろ退職をして独立をして、今はいわゆるフリーランスエンジニアとして活動をしています。エンジニア歴としては、2022年でちょうど5年目になります。

最近の趣味はゲーム。「スマブラ」「Fortnite」が好きです。好きなAWSのサービスは「AWSサポート」です。AWSサポートのみなさん、いつも本当にありがとうございます。

「ハッカー飯」について

自己紹介はこれぐらいにしておいて、さっそく本題に入りたいと思います。まずハッカー飯の紹介からさせてください。

ハッカー飯というプラットフォームは、技術や知識でアイデアをかたちにする人々、僕らは“ハッカー”と呼んでいますが、このハッカーがご飯を囲むような気軽さで語り合い、教え合い、つながれるオンラインプラットフォームとなっています。

もう少し概要について説明すると、ハッカー飯は、株式会社スタークロスの西田が作ったサービスとなっています。ハッカー飯の特徴としては、話したいことをもとに、エンジニアと1 on 1マッチングできる機能、エンジニア複数人と簡易的なイベントを行う食事会機能、そして興味のあることをもとに集まるコミュニティ機能が存在しています。

サービス開発の背景としては、「いわゆるエンジニア同士で気軽に、ハッカー同士で気軽に話せる環境があまりないよね」といったところがあり、そこを解決するためにハッカー飯というサービスを開発しました。

（スライドを示して）ハッカー飯にログインするとこういう画面になっていて、それぞれユーザーが話したいことリストみたいなことをカード形式で登録しています。

ここでは技術的な話や趣味的な話とかも行われていて、それぞれが「気になるボタン」を押すことによって、「この人はどんな話が気になっているのか」がわかり、気になるボタンを押してくれた人とマッチングして、メッセージを交換して話したり仲よくなったりするサービスとなっています。

（スライドを示して）食事会機能は、いわゆるエンジニアの勉強会なども企画されていたり、ただワインを飲む会というような、いわゆるリアルの飲み会、食事会も開催されていたりもします。

最近、ルーム機能も作成しました。こちらはハッカー飯上で「ルームを作成」というボタンを押すと画面が出て、入室することによってユーザー同士で気軽にカジュアルにお話しできる機能となっています。これによって、ユーザー同士がよりコミュニケーションがしやすくなるのかなと考えています。

そんなハッカー飯の運営メンバーですが、メンバー全員がそれぞれ本業がある中、副業でハッカー飯に携わっています。

開発スタイルですが、それぞれ副業で行っているので、毎週土曜日にDiscordのボイスチャンネルに入室して、各々開発を進めていく。そんなスタイルでやっています。

1時間開発して10分間休憩、みんなスマブラが好きなので、休憩時間中にスマブラをする。そんなサイクルでやっています。その日の夜には定例を行って、それぞれのタスクの確認や今後の方針について話し合いを行います。

収益化に関してですが、現状実はまだ収益化ができていなくて、コストをできるだけ抑えた構成となっています。今後、法人版のハッカー飯を作って、企業の中のエンジニアと気軽につながれるようなシステムを構築する予定です。ここまでがハッカー飯の紹介です。

ハッカー飯の初期の構成で採用した「Lightsail」

ここからが今回のテーマでもあるセキュリティ・モニタリングについて、ハッカー飯で取り組んだことをお話しします。まずは、セキュリティについてお話しします。

セキュリティの話に入る前に、ハッカー飯のインフラの構成について簡単に紹介します。本当にすごくシンプルな構成ですが、「Route 53」があって、「CloudFront」「S3」「Lightsail」、こういったサービスを使っています。

この中でLightsailと呼ばれるサービスは、もしかするとあまり聞き慣れないサービスかもしれないので、ここで少し説明させてください。

（スライドを示して）こちらがLightsailの公式ページに載っているスクリーンショットです。「Amazon Lightsail」というのは、ここにも書いてあるとおり、低価格の事前設定されたクラウドリソースを使用して、アプリケーションとWebサイトを構築できるサービスとなっています。

ポイントとしては、数回クリックするだけでWebサイトやアプリケーションを作成でき、費用対効果の高い月額料金で使用できる。これが主なLightsailのポイントです。

なぜハッカー飯の初期の構成でLightsailを選定したかというと、一番の理由としては、コスト管理が行いやすいからです。低額で使用できるため、コストの予算が立てやすいというメリットがありました。

また、3.5ドルのプランというのがあり、これを使用するとEC2を起動するよりも安く使うことができる。そういったメリットもあったのでLightsailを選定しました。

2つ目の理由としては、環境の構築を素早くできるからです。Lightsailでインフラ環境を構築する場合、先ほどのプランを選んでプラットフォームを選択して、必要なものを選択する。これぐらいのクリック（だけ）でインフラの環境が構築できるものとなっています。

いわゆるVPC（Virtual Private Cloud）やサブネット、インターネットゲートウェイすら作成する必要がない。すべて、いわゆる隠蔽化されている状態で作成されるので、そういったところをあまり意識しなくても誰でも構築できるのは、当時の開発メンバーにとって都合がいいものでした。

3番目の理由としては、EC2への移行も可能ということです。やはりEC2に比べるとLightsailはある程度制約、制限があって、EC2に移行したくなるタイミングがあると思います。そういった時にもLightsail上でスナップショットを取得することで、簡単にEC2へエクスポートが行えます。（スライドを示して）この「Export to Amazon EC2」というボタンを押すことで、EC2にエクスポートが可能となります。

Lightsailを運用していて困ったこと

そんなLightsailですが、運用していて困ったことがちょっとあって。まずはLightsailにIAMロールが使用できないことです。

EC2であれば必要な権限を付与してIAMロールを作成してアタッチすると思いますが、そういったことができないというのが問題としてありました。なので、いわゆるアンチパターンと呼ばれるものだと思いますが、IAMユーザーを作成してアクセスキーをインスタンス内部に格納する必要があります。

2点目としては、スケールアップが簡単にできないといったことがあります。EC2のようにインスタンスを停止して、インスタンスタイプを変更して、スケールアップして起動ということが、Lightsailでは行えません。

Lightsailの場合、スケールアップするにはスナップショットから作り直す必要があるので、今後、サービスが広く認知されてアクセス数が増えた際には、ちょっと困りそうだなと考えていました。

LightsailからEC2への移行

僕がジョインした後に発覚したんですが、そもそもアクセスキー・シークレットキーがプログラムの中にハードコーディングされていて、誰でも閲覧できる状態になっていました。これは外に漏洩した際にけっこうなセキュリティ上のリスクがあると判断して、最初にアクセスキーを廃止する取り組みを行いました。

方法はほかにもあるかもしれませんが、ハッカー飯ではこれを機にLightsailからEC2へ移行してIAMロールを使用することにしました。

移行の流れとしては本当にシンプルで、LightsailをEC2へエクスポートして、適切な権限に絞ったIAMロールをEC2にアタッチします。アクセスキーには有効化・無効化を切り替えるボタンがあり、まずアクセスキーを無効化にしてテストを実施した後、問題ないことを確認してからアクセスキーを削除する方法で行いました。

これによって、アクセスキーを最初に無効化にしてからテストを実施したほうが、なにか問題があった時にも切り戻しが楽かなと思ったので、こういった手順を踏んでいます。

本来であれば、ここで移行の苦労話とかをしようかなと思っていましたが、特につまずくこともなくすんなりと移行できてしまったので、逆に言うとそれぐらい簡単にシンプルに移行できるサービスなんだとあらためて認識することができました。

「AWS Single Sign-On」の採用

実はセキュリティ上のリスクが実はこれだけではなくて、そもそもAWSコンソールへのログインなども、これまでRootユーザーが使われていたということが発覚しました。これもやはり、ふだんの作業でRootユーザーを使うケースはほとんどないと思うので、これもアクセスキーを廃止したタイミングで管理を見直そうと考えました。

そこでハッカー飯では、簡単にセットアップできてユーザー管理を効率化できる「AWS Single Sign-On」を採用しました。

（スライドを示して）こちらを使うとこのような画面が表示されて、このようなポータルページが表示されて、必要な権限が表示されます。「Management console」というボタンを押すとAWSアカウントにログインでき、アクセスキー・シークレットキーの一時的なクレデンシャル情報を出力することも可能となっています。

Single Sign-Onについてもう少し詳しく説明すると、「AWS SSO」と略されたりすることが多いのかなと思いますが、こちらを使用することによって、ユーザー・グループの管理および認証を行えます。

先ほど紹介したようなポータルサイトにログイン後、所属しているグループに付与されている権限のみ使用を制限できます。

（スライドを示して）このように、例えばグループを2つ作って、それぞれにユーザーを所属させて、片方のグループには2つの権限、もう片方のグループには1つの権限のみとこともできて、今後開発メンバーが増えた時にもこういった構成のほうが管理が楽かなと考えたので、AWS SSOを採用することにしました。

以上がハッカー飯のセキュリティに関するお話でした。

（次回に続く）