この記事は HowTelevision Advent Calender 2023 の15日目の記事です。14日目はプロダクト本部プラットフォームエンジニアリングチームの縄司さん (
id:nawajie) によるハウテレビジョンの事業を支えるデータ基盤 - ハウテレビジョンブログでした。
外資就活の開発チームでソフトウェアエンジニアっぽいことをしている山本です。現在、外資就活の開発チームでは技術負債の解消に取り組んでいます。今回はその技術負債解消の一環で実施したセキュリティ対応でやらかしてしまった話です。
※負債解消プロジェクトの詳細についてはこの記事を参照ください
背景
弊社では社内で利用する業務用ツールとしてWebアプリを内製し運用しています。その歴史は古く、私が知る限り2015年より以前から改修を繰り返しながら使われてきました。しかしながら、社内向けのツールということもあり、定期メンテナンスなどの優先度は高くありませんでした。
そして今回、負債解消プロジェクトの一環としてセキュリティの全面的な見直しがなされ、この社内向けのWebアプリも対象となりました。事件はこのWebアプリがデプロイされているAWSのEC2に対してセキュリティ対応のメンテナンス施策を適用したことにより発生します。
障害発生
とある部門の担当者よりSlackの障害報告チャネルに一報が入ります。
この社内向けWebアプリの機能のひとつとして、画像ファイルをAWSのS3にアップロードするというものがあります。それが正常に動かないとのこと。急いで原因調査に取り掛かります。
原因調査
まずはエラーログを確認します。
Webアプリのログには、画像ファイルのアップロードに失敗したというメッセージとともに "Unable to locate credentials" の文字が。
なるほどなるほど。AWSへ接続するための認証情報がないのね。そりゃ失敗するよね。
って、なんで？？ほんとに？？？
画像ファイルはEC2にインストールされたAWS CLI経由でS3にアップロードされる仕組みになっていました。そのAWS CLIで使用するcredentialsがないと言うのです。 Webアプリが稼働しているEC2にログインして "aws configure list" を実行してみます。
$ aws configure list
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key <not set> None None
secret_key <not set> None None
region <not set> None None
…あらやだ。確かにないわ。
原因判明
さて画像ファイルのアップロードが失敗する原因はわかりました。しかしなぜあったはずのcredentialsが突然なくなったのか。
その原因を探るため我々はPullRequestの奥地へと調査に向かった。弊社ではterraformでインフラを管理しており、terraformのコードはGithubで管理しています。なのでGithubで関係しそうなMerge済みPullRequestを中心に探します。 するとそれらしきものが見つかりました。
"# EC2 instances should use Instance Metadata Service Version 2 (IMDSv2)"
これはこの脆弱性に対応するために適用されたもので、IMDSv1のままになっていたのをIMDSv2に変更したというものです。この変更が適用された直後から、この障害が発生したことがわかりました。
IMDSv2になったことで、これまで単純にGETメソッドで取得できていたcredentialsが、取得する前にまずセッションTokenを取得して、その後credentialsをGETするという流れに変更になりました。これだけであれば、AWS CLI が対応していれば別に問題ないはず…
( ﾟдﾟ)ﾊｯ!
EC2に設定されているAWS CLIのバージョンを確認。
バージョンが 1.9 やないかい！
IMDSv2に対応するには AWS CLI 1.16以上 が必要でした。
どうすればよかったか
まず反省すべきは、社内向けのWebアプリということもあり、商用プロダクトと比べてテストやterraformのコードレビューが楽観的になっていたという点です。弊社ではリリース前のコードレビューが徹底されています。しかしこのterraformのレビューでは、レビュアーもレビュイーもその変更により影響を受ける関連ライブラリにまで意識が及んでいませんでした。
次に、弊社では本番環境へのリリース前に必ずステージング環境でのテスト・動作確認を行う運用となっています。しかし今回の場合、ターゲットがEC2（インフラ）ということもあり、そこにデプロイされているWebアプリの動作確認がおざなりになっていたことは否めません。
最後にE2Eテストが未整備だったことも原因の一つとして考えられます。社内向けといえども、きちんとE2Eテストを整備していれば「ファイルのアップロードが失敗する」というケースを検知できたはずです。
まとめ
「多分ダイジョブだろう」と思ったときに障害は発生します。 今回の障害を糧に、E2Eテストの整備やレビュー精度の向上に取り組んでいきたいと思います。障害を100%未然に防ぐ完璧な仕組みは存在しませんが、それに近づける努力はすべきだと考えており「人の意識ではなく仕組みで防ぐ」ということを意識して日々改善に取り組んでいきたいです。
そんな飽くなき改善を続けるハウテレビジョンでは、組織拡大のためにソフトウェアエンジニアを募集しています！
