ふと思ったのだけど、githubに秘密鍵をpushしちゃいけないのは頭ではわかるんだけど、それとgoogle driveに機密情報をアップロードするのと何が違うのかわからんくなってきた
— ryoppippi (@ryoppippi) 2026年5月3日
教えて偉い人
なんでGHはダメでGDは良いのか
私の場合の答えは「まず情報セキュリティを勉強しましょう」ということになります。
以下のIPAが公開している資料がわかりやすいのでご覧ください。
「そんなもん分かってるわ。その上での話だよ。」と言う場合に対する答えは「人や会社の リスクに対するポリシー による。」になります。あるいは「要はバランス」
返信の中に「情報セキュリティ」というワードが見当たらなかったのが気になったので書いてみようと思います。
以降は私の浅い理解の話。上のIPAの資料を読んでもらえれば読む必要はないと思います。
ISMSやらなにやらで聞くかと思いますが、おそらく「情報セキュリティ」というワード自体がかなりフワッとした印象だと思います。情報とセキュリティというワード自体に具体性が無いせいでもあります。
なのでこういった具体的な事案に対しては「こうすべき」という各自の想いが出るのでしょう。
情報セキュリティは守るだけでなく活用も含める
守るだけなら簡単です。「外部サービス使うな。OSSなんて使うな。全部内製しろ。ハードウェア含めてな」です。
さて現実的でしょうか？無茶な話ですよね。
せっかく安価で手に入るようになったパソコンやネットワーク、ソフトウェアを「セキュリティ」で使えないのは商売にならないです。
守りつつ活用できる境界を探るという営みが情報セキュリティであるというのが私の理解です。
守りつつ活用するにはリスクに合わせる
手頃に活用しつつ、守りもしっかりしたいとなると、いろいろな決まり事ができてきます。その線引きが必要になります。
それを決めるために事象を想像するわけです。
「Google Driveに上げた機密情報」という点については、それによって何が懸念なのかを深掘りする必要があります。
「Google Driveに上げた機密情報が流出した」では足りません。もう少し具体性が必要です。「Google Driveに上げた機密情報が共有リンクが漏れて流出した」とか「Google Driveに上げた機密情報がGoogleの中の人に盗み見られた」とかです。どちらも同じ流出ですが、だいぶ違いますよね。
その「事象」が「どれぐらい影響があるのか」とか「誰が起こし得るか」とか「どれぐらいの発生確率か」を考えます。他にも考えることがあるかもしれません。
これが「リスク」です。「リスク」を見て、初めて「どう扱うか」を考えることができるようになります。
リスクの対応
リスクの対応はいろいろありますが、「低減」「回避」「移転」「保有」のいずれかとなります。
Google Driveに機密情報を上げる例で考えてみましょう。
- 低減: 権限を絞ったり、2FAで強化！
- 回避: Google Driveは禁止！
- 移転: 該当なし（※わかりやすいのは火災保険などです。データ流出に対する保険があればいいんですけど、ビジネスになっていないのはそういうことなんですよねー）
- 保有: その機密情報ぐらいなら、上げてもいいんじゃない？後は問題にならないように祈ろう
こんな感じです。これを具体例に対して考えてみましょう。
「Google Driveに上げた機密情報が共有リンクが漏れて流出した」のケースでは、社員の誤操作で簡単に起きそうです。ですがGoogle Driveには組織内だけで共有リンクを知っている人に共有することができますし、それを組織の設定にすることができます。つまりリスクの低減ができます。ここまでできると「簡単に発生するけど、組織内の人間に見られるぐらいなら社内でもみ消せばええし許せるかな？」と思えてきませんか？もちろん同じ組織でも全く関係ないグループに見えるのは大問題になるでしょう。それなら他の策を考えないといけませんね、となります。
「Google Driveに上げた機密情報がGoogleの中の人に盗み見られた」のケースは、Googleがお金を取ってまでそんなことはしないという信用を盾にリスクを許容（保有）するわけです。
しかし、こんなルールを一つ一つ真面目に決めていると会社は回らないです。世の中はリスクだらけ。だから大半はフワッとしていることでしょう。「Winnyを使うな」とか直接的に伝えるほうがわかりやすいものはそうするし「コンプラを守れ」とかのワードに凝縮したりするわけです。
機密情報をGoogle Driveに上げる話は？
ここまで読んでいればこの答えは「リスクのバランスが取れているならいいのでは」ともいえるし「金融ではNGです *1」ともいえるでしょう。
そんな話はどうでもいいから、具体的にどうなんだよ
大半は上記のことなんかより、具体的な答えが欲しいのではないでしょうか。少し考えてみましょう。
GitHubに秘密鍵をpushする
秘密鍵といっていますが、ここではSSH鍵、環境変数（APIキー等）を想定します。
秘密鍵にパスフレーズをつけておけばよいというルールにするのはどうでしょうか？
「パスフレーズが破られたらどうするんだ？ファイルを入手できたら総当たりで破られるだろ」と言われたら、この案はダメですね。パスフレーズをどう共有するんだという課題もありますし。
そもそもGitHubで管理せず、適切なストアがあれば使うのはアリではないでしょうか。
SSH鍵ならそもそも各自に公開鍵を提出させて個別に登録するという手もあるでしょう。本来あるべき姿ではありますが、これも、ある人の秘密鍵管理がガバガバだとダメなんですよね。
APIキー等は権限がついた共有フォルダとかも個人的には良いのではと思います。もっと厳しくいくなら、AWSならSecrets Manager、AzureならKey Vaultに置いて、その参照URLだけを共有フォルダに残すのも手です。共有フォルダも見れて、AWSアカウント/Azureテナント/リソースの関係者しか見られないなら十分じゃないでしょうか。これを環境に合わせて権限を絞るとよいでしょう。
「プログラムのコードで参照値をログ出力させてログから流出したらどうするんだ」と言われたら、コードレビューをしっかりやれ、となります。
「コードレビューをしっかりできなかったら漏れるじゃん」と言われたら、流行りのAIでチェックさせるのが有効ではないでしょうか。実際効果ありますよ。
「AIがコードを見るということはAIを運用している企業にコードを見せている可能性がある。これはリスクだ」と言われたら、そうですね、となりますし、うるせえこまけえことチクチク言いやがっててめえも考えるんだよ、ともなります。
そもそもAPIキーを使わなくて済むならその方法を採用していくのも良いでしょう。OIDCを使ったフェデレーションをサポートするところも増えてきました。
Google Driveに機密情報を上げる
閲覧すべき一部の社員のみに閲覧権限が付いた状態で共有できるならいいのではないでしょうか？
「設定ミスしたらどうするんだ？」「関係ない人が見えたらどうするんだ？」と言われたら、この案はダメですね。
社内に共有フォルダを設けるのはどうでしょうか。
「サーバ運営者が盗み見ることができたらどうするんだ？」と言われたら、厳しいですね。
じゃあ紙に印刷して手渡しでいいんじゃないでしょうか？
「ごみ回収時に清掃業者に見られたらどうするんだ？」と言われたら、シュレッダーにかける、あるいは目の前で焼却するルールにすればよいのではないでしょうか？
こんな感じで具体的な事象（リスク）に対して「もし～」を考えていくとよいのではないでしょうか。私の上記の内容はあまりにも浅すぎるし方向性がおかしい気はしますけど。複数人でやると面白いと思いますよ。付き合ってくれる人がいればですけどね。
おわり
ちゃんとやるなら、ISO 27000シリーズやらNIST SP800-53やら読めとか色々あるんですが、そんなもん頭に入るわけないだろいい加減にしろ
否定する（守る）だけなら簡単なんですよ。やらなきゃいい、禁止すればいい。でもそれだと業務が回らない。だからセキュリティは難しい。だから嫌い。
*1:勝手に金融の文脈で語りだすのはどうかと思いましたし、じゃあ具体的にどうしてるのか答えないのは聞かれてないからか知らないからか
