前回、自らAccessTokenをGitHubに公開するという大失態を犯した。 次からは同じ失敗をくりかえさぬよう、対策を考える。
原因
そもそも、コードとおなじところにアップロード用バッチを配置したり認証データを配置するのが問題。
- 前回のような事故に繋がる
- 認証データがあちこちに点在して危険
- どれがプロジェクトのコードかわかりづらくなる
- ファイルサイズが肥大化する
ただ、セキュリティに関しては根本から解決するのは結構むずかしそう。だから放置していた。
解決案
データベースで認証データを一元管理する
- 何のDBMSを使う？
- 暗号化する
- 何の暗号方式を使う？
- どうやって暗号化／復号化する？
- 何の暗号方式を使う？
アップロード用ツールを作成する
暗号化のところが最もむずかしそう。
最も簡単な解決方法
これまでのbatとtsvを1箇所に配置する。
プロジェクトごとにup.batファイルを用意して、C:/GitHubApi/FirstPush.bat %ユーザ名% %リポジトリ名% %リポジトリ説明% %リポジトリHomepage%を記述する。リポジトリ名は例によってfor %%I in (.) do set REPO_NAME=%%~nI%%~xIで取得する。
C:/GitHubApi/FirstPush.batファイルにはリポジトリ作成処理がある。
問題点
C:/GitHubApi/FirstPush.batというコードをみれば、どうやってパスワードを取得しているかが記述されている。ここから漏洩してしまうかもしれない。
- batの内容を追っていけば認証データのファイルパスが判明してしまう
- それがプロジェクトフォルダ内ごとに存在する
でも、少なくとも今回のように自らネットに漏らしてしまう事故は減らせる。やる価値はある。というかやるべき。今回の自爆漏洩に関しては、これだけで解決できる。
さらなる問題点
さらに以下のような改善点が考えられる。
- 認証データの保存パスがわからないようにする
- 認証データは暗号化する（平文で保存しない）
- 認証データを復号化する手続きが分からないよう難読化する
- 認証データは違うデバイスに保存する
- 毎回パスワードなり秘密の質問なりに答えるようなツールを作る
平文で保存していたらファイルの一括検索やgrepですぐに抜き取られそう。 暗号化しておけば、その心配はない。
でも、平文を暗号化する手続きがプログラムのコードとして見えてしまったら復号化されてしまいそう。 だからC/C++のネイティブアプリが解析されにくくていいと思う。 batなどスクリプトは丸見えだし、C#も逆アセンブルできる仕組みなので、ネイティブアプリのほうが安全か。
だから専用ツールがほしい。でも、起動時にパスワードの入力を求めることになってしまいそう。 ただ実行できるなら誰でもできるから。
- 自動化できないと意味がない／完全自動化するとセキュリティの意味がない
- パスワードだけでも危険／ないよりマシ
どれが正解とも言いがたい。
保存と通信のときに暗号化するとか、メモリダンプから守るとか、キーロガーとか、後ろから盗み見とか、一体どこまで考慮すべきか。素人には想像もつかない。
どうするか
以下、あくまで理想の妄想。
専用ツールを作り、exe化して、処理内容を難読化する。batよりマシという程度でいい。 認証データの暗号化もやる。どちらも平文でgrepされない程度の暗号強度でいい。
アップロードを実行するたびにパスワードを求めない。離席するときはWindowsパスワード入力画面にすることで代用する。だからアップロード時はパスワード不要の完全自動化ツールとして使える。
USBメモリが使えるなら、認証データを入れておき、常に持ち歩く。 PCにある暗号化ツールと連動して復号化できるようにすれば盗難や紛失の時にも少しは安心。
これなら、ある程度のセキュリティを保ちつつ、自動化できる。 たとえ暗号化されていても記録があれば、忘れたときに復元できる希望はある。 このくらいならできなくはないと思う。とても大変そうだけど。
所感
まずは最も簡単な方法で自ら漏洩することを防ぐことからやる。
