サーバ本番機の秘密鍵をなくして困った話

雑記 IT技術

この記事について

このブログは私自身がほぼゼロからWEBシステムを開発し運用していますが、先日本番機秘密鍵をなくすというトラブルにみまわれました。そのときのことについて記事にしてみました。

ちなみに、以下の記事に私のブログのシステム構成を簡単に書いています。もしよろしければこちらと合わせて読んでいただけますと幸いです。

目次

何が起こったか

問題の端緒はシンプルでした。普段運用に使っていたPCが壊れてしまい、起動しなくなってしまったということです。

ソースコードはGithubのプライベートリポジトリに保存してあるし、Githubにアップロードしたくないパスワードなどのクレデンシャルは別でバックアップとっていたから大丈夫...と思っていたら、バックアップの中に本番機にアクセスするための秘密鍵が欠けていました...

たったこれだけのことですがとても困ったことになっていました。

困ったこと

大きな問題とは、本番機にログインできなくなったことで、本番機のメンテナンスができなくなってしまったことです。今後新機能の開発をした際に本番にリリースをしたり、不具合発生時にサーバにログインして復旧作業を行うことができなくなってしまいました。

幸いブログの記事作成自体は、CMSを自前で作っていたため、直近の運営に問題はなかったものの、今後機能的な発展ができず、システムダウンが起きたらもう二度と復旧できないという状況に陥っていました。

唯一の救いはCMSを作っていたことです。CMSを作っていたことで、表面上に出るデータ+アルファくらいはCMS上から閲覧できました。

ただし、CMS上から全データの一括取得をする機能は設けておらず、全てのブログ記事をひとつずつ管理ページにアクセスして取得する必要がありました。

どのように乗り切ったか

やったことはとても単純です。全てのブログ記事の管理ページにアクセスして記事データを全て手でコピーしたあと、新しい公開鍵・秘密鍵でアクセスできる新しいサーバに、手でもう一度ブログの記事を入力し直しただけです。

想定外のトラブルでしたが、Active/Standbyで構築していたメリットがここで生きました。

Activeシステムのデータを手でコピーした後、まずStandbyシステムだけ新しいものに入れ替え、Standbyシステムに対して手入力でデータをいれました。Standbyシステムで問題なく反映されたと確認できたら、今度はActiveシステムを再度構築しなおし、データを反映させました。

これにより、ActiveとStandbyの違いを確認しながら作業ができたのでリスク低く対応できました。また、本件作業中、一般の方の見た目上は一切システム停止なく稼働させることができました。

まだ、半年ほどしか運用してなく記事数も少なかったというのも救いでした。もしも何年も運用していた場合データが膨大すぎて手作業では対応できず、スクレイピングツールなどの作成も必要でした。もっとも、スクレイピングツールで作業ができたとしても、抽出に今回かかった時間以上の時間がかかっていた可能性があります。

教訓と再発防止策の検討

本番作業するPCも運営システムの一部であるという認識が甘かったのが最大の反省と思ってます。その認識が欠けており、秘密鍵のバックアップを忘れるという事態に陥ってしまいました。一番大きい問題はこの認識かなと思っています。

今回は私個人の個人運営システムであり、私個人の認識を改めるだけでOKと思っています。もっとも、会社経営のように複数人で運営するシステムでしたら、現行担当者の認識改めるだけの再発防止は不十分と思います。他のマネジメント的なアプローチが必要です。

例えば、PC台数分のPCのメンテナンスという負荷は増えますが、作業PCを増やして、仮にPC1台が故障してデータ消失してももう一台がフォローできるようにする体制を作るなどが考えられると思います。予算の都合上どうしてもPCを複数台用意できない場合は、チェックシート方式、新規担当者へのラーニング実施など仕組みで解決する必要があると思います。

なお、再発防止対策として、もしもの時の利用として秘密鍵を使わずにアクセスできる入り口を用意するなども考えられますが、それは不正アクセスリスクを高めることなので対策としては筋が悪いかなと思っています。

ここまでネガティブな教訓を述べましたが、一方でポジティブな教訓もあります。ここまで準備していた各種冗長化対策が全く生かされなかったわけではないという点です。

特に大きかったのは、Active/Standby構成に助けられたことです。慎重かつ時間を要する作業ではあったものの、この構成のおかげで、旧システムと新システムの見た目を確認しながらできました。もしも本番環境1個だけのシステムであったら、もっとリスクのある作業をしていた可能性があります。

終わりに

いずれにしろ、不幸中の幸いにいろいろ助けられたという経験でした。個人運営システムだから自己反省のみで済まされますが、誰かのシステムの運用委託で本件を起こしていたら反省だけで済まず、責任が問われます。

実業務にも生きる経験を培うという目的もあって個人ブログを自前システムで運営していますので、引き続き緊張感持って運用できればと考えています。

Photo by Nik Shuliahin on Unsplash

 みやうデジタルラボ - にほんブログ村