平素はお世話になっております。
ピタリ株式会社 代表取締役 山本と申します。
本日 2024年10月10日 16:30ごろより発生したサービスへの接続ができなくなる問題について、大変ご迷惑をおかけいたしましたことをお詫び申し上げます。
サービスが始まって以来、初めての4時間弱にわたるサービス停止を受け、今後このような事象を発生させないためにも、問題の経緯、原因、今後の対策について、技術的な観点からも記録として残しておこうということになりましたので、ブログ記事としてここに記します。
状況の経過
発端 16:30
本日は12日のメンテナンスに備え開発陣が最終のチェックを行っており、16時ごろよりデータベースの設定と現状ステータスの確認も踏まえ、固定IPアドレスのある社内より、AWS VPCの非公開専用サーバー経由でデータベースサーバー（以下DBサーバー）管理画面へアクセスしておりました。
その中で、管理ユーザーアカウントがアクセスできる接続元を制限する目的で、
‘管理ユーザー’@’%’
となっているところを、管理者以外のユーザーの仕様と統一するため、
‘管理ユーザー’@’ローカルセグメント.%’
と変更してしまいました。
ここで、データベース管理画面がログアウトされDBサーバーにアクセスできなくなったことが判明し、同時に同管理ユーザーでアクセスしているアカウント管理APIサーバが、データベースにアクセスできなくなり、サービスがダウンすることとなりました。
復旧作業開始 16:32
通常のAPIサーバーやアプリケーションサーバー（以下APサーバー）から接続するためのユーザー権限は、非常に限られた権限しかなく、ユーザー権限を設定するGRANTコマンドの権限が割り当てられていないため、まずは管理者権限でのアクセスを試みます。
この時点で、取り急ぎAWSのサポートに問い合わせと復旧の依頼をかけました。
復旧作業 16:50
問い合わせの電話に対応しつつ、開発者がいくつかのサーバーからDBサーバーへのアクセスを試みるものの、’管理ユーザー’@’ローカルセグメント.%’と設定してしまったためか、どのサーバーからもアクセスができない状況となっていることがわかりました。
復旧作業 17:00
この管理ユーザーは、限られた用途にしか利用されていないため、AWS RDSの設定におけるマスターユーザーであることがわかり、AWS管理コンソールより強制パスワード変更処理を実施いたしました。しかし、状況に変化はなく、何度かパスワードの変更を実施します。
復旧作業 17:30
ここで、先ほどの非公開サーバーからパスワード無しでアクセスを試みたところ、アクセスができることがわかりました。しかし、ほとんどのコマンドを受けつず、SHOW GRANTコマンドでは、GRANT USAGEとなっており、なんの権限もない状態となっていました。
このときは、全員が復旧第一を目指して何らかの調査を行っており、正確な状況とはいかないまでも整理すると以下の状態となっていると予想されます。
◯’管理ユーザー’@’%’ は 強制パスワード変更で設定されたパスワード、権限維持
◯’管理ユーザー’@’ローカルセグメント.%’ は パスワード無し、権限無し
のような権限設定状態となっていたと推測されます。
復旧作業 18:30
上記の状態を予想し、ローカルセグメント以外からのアクセスを試みるため、AWSのファイアウォールにてIPアドレスの制限を適切に設定した上で、弊社内から直接RDSにアクセスできるよう公開設定を変更しました。
復旧作業 19:00
弊社からのアクセスを試みるものの、今度はアクセス自体ができない状態となっており、改めて強制パスワード変更を試みます。
復旧作業 19:20
強制パスワード変更を実施し、無事に社内からアクセスが可能となりましたが、まだ現状ではVPC内からのアクセスはできない状態が続いています。
ここで’管理ユーザー’@’ローカルセグメント.%’への権限設定を試みるなどしていますが、結果はエラーとなり正しく設定ができない状態が続いています。
復旧作業 19:30
ここで、新たにユーザーを追加し、管理権限を付与する操作を行いますが、ユーザーを追加することはできるものの、グローバルな管理権限の付与についてはエラーとなる状態になっています。おそらくRDSでは全ての権限を付与することはできず、この情報ページにあるような操作を行う必要があるようです。
https://repost.aws/ja/knowledge-center/duplicate-master-user-mysql
復旧作業 19:40
新たにユーザーを追加したものの、ユーザーの追加ができる場合は削除もできるということで、 ‘管理ユーザー’@’ローカルセグメント.%’を一度削除し、その上で再びマスターユーザーのパスワードを強制変更することで、問題発生前の状態に戻ると予想し、実際に操作を実施いたしました。
復旧作業 19:50
ここでまでの作業で、再びVPC内からDBサーバーにアクセスができることが確認され、APIサーバーからも同様となり、サービスが復旧していることが確認されました。
復旧作業 20:00
DBサーバーの公開設定を非公開に変更し、さらに復旧過程で作成された追加ユーザーに対して、今後のメイン管理者となるよう正しい管理権限を付与いたしました。
復旧作業 20:30
第一報として、お知らせを更新し公開いたしました。並行して、セールスノートユーザー様宛への一斉メールの手配に取り掛かりました。
事後処理 21:00
お知らせメールの配信を手配しました。
事後処理 22:30
すべてのお客様にお知らせメールが配信されたことを確認し、作業を完了としました。
セールスノートでは、日時バックアップの他に、データメンテナンスが伴う場合には、メンテナンス開始時のバックアップを保存するようなフローが確立しております。
しかし今回はデータのメンテナンスを行わなず、また、すでに運用に問題がないことが確認されている接続元「@’ローカルセグメント.%’」の設定をということで、アクセスが集中する時間帯にも関わらず設定を反映してしまったことによる問題と、
合わせてマスターユーザーに接続元の制限を適用した場合起こる問題ということがわかりました。
この設定の反映時に、開発陣から山本への確認があったものの、安易にOKを出してしまったことも問題だと痛感しております。
今後、このようなことの無いよう、フロー上の改善として改めて作業時間帯の制約を徹底することとし、さらに技術的な改善としてセキュリティの問題のない範囲での管理ユーザーの冗長化を実施いたします。
最後に、お電話等でお問い合わせいただいたお客様や、不具合をご連絡いただいたお客様、その他のすべてのお客様に対し、深くお詫び申し上げます。
引き続き、安定と改善を目指してまいりますので、セールスノートを何卒よろしくお願い申し上げます。
ピタリ株式会社 代表取締役 山本 優