鍵ファイルのセキュリティについて

昔、一人暮らしを始めた頃、 夜遅くに自宅アパートに帰ってきて、いつも鍵を入れているポケットに鍵が入っていない事に気がついて、アタフタした事がありました。 その時は飲み会があり、鍵を落とさないようにバッグに入れてあったので、30分ぐらい玄関でモタモタしていたけど、鍵が見つかり自宅には入れたんですが、 人はいつもと違う事をすると、よく無い結果を招く事があると思い知らされた記憶なので、できるだけ行動を習慣化してミスをなくす事が重要と理解しました。 でも、いまだに部屋のどこにモノを置いたのか忘れて、年中探しているダメな自分に呆れ果てています。 そんな鍵から思い出される昔の記憶はさておき、 Web系プログラミングでよく利用される鍵ファイル（いわゆる、公開鍵の類）を、現在構築中のプロジェクトでどのように管理するかと言う話を プロジェクトメンバーと話して、いろいろな気づきがあったので、ブログに残しておきたいと思います。

そのチームの現状

多くの開発チームがやっているように、Githubに開発プロジェクトのリポジトリを格納して、Dockerを利用してローカル環境を立ち上げる方式です。 本番は、AWSにEC2インスタンスで構築されたサーバーに、デプロイするという、よくあるWebサービスプロジェクトなんですが、 その時に、サービス内で利用するあらゆる鍵をそのプロジェクト環境内に保持して、Githubにアップされていました。 もちろん、Githubは、有料利用をしていてPrivateでリポジトリが管理されており、以下のような階層構造で保持されていました。 root/ ├ keys/ │ ├ 鍵ファイル1 │ └ 鍵ファイル2 ├ public/ │ └ index.html └ docs/ webでの公開はpublicフォルダで行われているので、keysフォルダは、webを通じてのアクセスはできないという意図で、githubに保持されて運用されていたんですね。

Githubはよく情報漏洩をしているので危険?!

ネットで調べてみると、Githubは、よく情報漏洩を起こしていて、2013年には、年間に1200万件もの認証情報が流出しているとのこと。 TECH+ : 2023年はGitHubから1,200万件を超える認証情報が流出 鍵ファイルをネットクロールして、不正に集めている、マイナー（AIのマイニングで収益を得る人の事）というハッカー的な人たちが、GithubやAWSを主に狙っているため、 Githubに、鍵ファイルの実態を置くことは、そもそもよく無いという意見と、 Githubのセキュリティが突破されない限り、盗まれる事がないはずという意見がぶつかっていました。

よくやる鍵管理方法

Githubに鍵を入れないとしたら、他の会社や一般的にはどういう方法で管理しているかというと、 GoogleDrive、Box、Dropboxという、セキュリティ性の高い外部ストレージに鍵ファイルを置いて、情シス担当者が管理者となりその人のみアクセスできる状態にして、 個別に鍵を渡すという手法で、Githubとは別の場所管理にする事が大半です。 中には、ローカルPCでのみ保管するという手法のチームも過去に経験した事がありますが、 利便性が激減するという鍵保管方式は、開発員としては反対するしかありません。 手元に持っている、USBスティックメモリーに格納しても良いですが、物理の場合、壊れる場合もあるので、別リスクが発生してしまいますからね。 パソコン端末も然りなんですよ。 あと、他には、鍵ファイルではなく、環境変数としての文字列で、多少の暗号化された状態で保持するというケースもあり、 こちらは、復元方法をGithubに設置するのであれば、どれだけ暗号化されていようが、復元方法が漏洩するリスクも伴い、危険性が高いと言う意見も出ていましたね。

結局はデプロイサーバーにコピーして使う

でも、どんなに厳重に鍵ファイルを管理しようが、 デプロイしたサーバーには、コピーされた鍵ファイルを設置する必要があるんですよね。 今回の議論は、「Githubに鍵を置くかどうか」というこの視点のみでの議論で、 鍵ファイルを別に置く事で、鍵ファイルの流出が皆無になるという話ではないんですよね。 本番環境がハックされたら、開発サイドでどれだけセキュアな保管を行っていても漏洩リスクはダダ漏れレベルである状態なんです。

結論

その開発チームは、全員で5名いて、 正社員の人が1名、自分のような業務委託の開発員が4名いる構成で、 最終的にその開発したWebサービスは、正社員の人が運用をし続けていく事になる事を考えると、 その人がやりたい事を採用する事にしました。 運用がどれだけめんどくさくなっても、所詮は業務委託の人は意見すべきでは無いという事ですね。 あと、Githubや本番における漏洩が発生しても、責任所在の人がリスクを十分に理解した上で、管理方法を決めるということが1番の結論であるという事に全員で認識一致することができました。 今回のディスカッションは、いろいろな鍵ファイルの漏洩リスクと、よりセキュアな管理方法についての意見を出し合う事ができたのが、非常に有意義でしたね。

あとがき

鍵ファイルの扱いは、センシティブというのはよくわかるが、 想定上にセキュアにこだわって、利便性が失われている開発現場もこれまでたくさん見てきました。 意味のないサーバーアクセスセキュリティを強化していた会社が、管理担当者が退職して、そのサーバーにアクセスできなくなったり、 暗号化して保管していた鍵ファイルの復元方法がわからなくなってしまったり、 そんなお間抜け担当者も多い中、よりセキュアを追求する姿勢は、間違った方向性ではないという認識です。 なんか、デジタルファイルなのに、物理のような、何重にも扉が付いている金庫にしまってあるような事を創造すると、少し違和感を感じてしまうのは、自分だけなのでしょうか？ いっそのことGithubではなく、独自に立てたGitリポジトリ管理システムを使うと言う手もありますからね。 議論の幅は果てしないというのも事実かも。