オープンソースの認証情報を漏えいから守る

今月初め、ChALkeRという研究者が、npmパッケージに含まれる認証情報の漏えいに関する調査結果を公開しました。調査では、npmやGitHubのトークン、パスワードなどの認証情報が、公開されているnpmパッケージやGitHubリポジトリに頻繁に含まれていることが明らかになりました。実際、npmの上位15パッケージのうち13個が、認証情報が漏えいしたパッケージに依存しており、その利用者を危険にさらしています。

ChALKeRの投稿は一読の価値があり、私の知る限りnpmに特化した認証情報漏えいの初めての分析ですが、問題自体は新しいものではありません。3年近く前には、GitHub検索で簡単に秘密鍵を見つけられ（Chromeチームの鍵が露出したとも報じられ）、Google検索ではさまざまな個人情報が見つかることがありました。コードが見つけやすくなるほど、こうしたミスも発見されやすくなります。だからこそ、対策を講じる必要があります。

適切なセキュリティガイドラインに従うために、npmのセキュリティに関する10のベストプラクティスをまとめたSnykのチートシートをダウンロードしましょう。Node.jsやJavaScriptの開発者に役立つ、安全なnpmの利用方法を学べます。

認証情報の漏えいを警戒すべき理由

認証情報の漏えいとは、さまざまなアカウントへのアクセスを可能にするシークレットが露出することです。

漏えいする認証情報で最も多いのは、パスワード、APIキー、SSH秘密鍵です。これらの鍵があれば、自社のものでも攻撃者のものでも、自動化ツールが新しいパッケージバージョンの公開やコードの削除などの操作を実行できてしまう場合があります。各鍵で許可される操作の範囲は、鍵やシステムによって異なります。

オープンソースパッケージを利用している場合、特に注意すべきなのは、npmトークンやGitHubのデプロイキーなど、新しいコードの公開を可能にする認証情報です。これらにアクセスした攻撃者は、悪意あるコードを含む新しい「修正版」を簡単に公開でき、あなたが気づかないままインストールしてしまうことも少なくありません。

オープンソースプロジェクトをどこかでホストしているなら、実行環境に関する情報の漏えいにも注意が必要です。npmに限らず、AWSのキー、SSH秘密鍵、各種システムのパスワードが露出する可能性があります。これらの鍵のいずれかを使って攻撃者がシステムにアクセスし、知的財産やユーザーデータを盗んだり、無料でコンピューティングリソースを利用したり（その請求はあなたに回ってきます）するおそれがあります。

オープンソース開発者がすべきこと

リスクを認識するだけでなく、開発の流れにいくつかのベストプラクティスを取り入れ、ミスを防ぐための多層防御を整えましょう。具体的には、次のような対策が考えられます。

一律にgit add *を実行しない

ワイルドカードを使うと、共有するつもりのないローカルファイルまで簡単に含まれてしまいます。サブフォルダ全体を追加する場合（例：git add dirname）は特に注意が必要です。隠し（dot）ファイルも含まれるためです。

ワイルドカードの代わりに、コミットするファイルを一つずつ指定するか、git add -pを使って追加する変更を確認しましょう。

.gitignoreと.npmignoreに機密ファイルを指定する

gitとnpmには、パッケージ化やコミットから除外するファイルを指定するローカルファイルの仕組みがあり、機密ファイルの誤った取り込みを防ぐ対策として使えます。除外対象を指定しなくても、npmは特定のファイルを無視しますが、gitはすべて含めます。既定の設定にかかわらず、どちらのツールもあなたほどアプリケーションを把握しているわけではないため、これらのファイルは自分で編集するのが最善です。

注意すべきファイルの例：

• CI設定ファイル（例：.travis.yml、circle.yml）

• Dockerfileとdocker-compose.yml

• ビルド出力ファイル（例：gypi）

• 独自のデプロイスクリプト（例：/deploy/や/scripts/以下のファイル）

ChALKeRの投稿にはほかにもいくつか例が挙げられています。また、GitHubのサンプル.gitignoreファイルも参考になります。

npmのより広範な既定の除外設定が導入されたのはnpm@2.14.1からです。必ずこのバージョン以降にアップグレードしてください。

CIから公開する場合は暗号化するか環境変数を使う

CI経由でnpmに公開する場合、CIからnpmトークンにアクセスできる必要があります。そのトークンをCI設定ファイルに誤って追加し、露出させてしまうこともあります。

可能であれば、代わりに環境変数にトークンを格納しましょう。ソース管理に含めず、出力上で難読化できます（少なくともTravisとCircleでは可能です）。何らかの理由で鍵をソース管理に含める必要がある場合（たとえばGitHubにコンテンツをコミットし直す場合）は、必ず十分に暗号化してください。

git-secrets：認証情報を含むコミットを防ぐgitフック

AWS LabsのMichael Dowlingが最近、git-secretsという便利なツールを公開しました。このツールはgit commitにフックし、認証情報と思われるパターンが含まれている場合はコミットを中断します。ファイル名に基づく前述の保護策を補完する、内容に着目した安全策として有効です。

このツールのように、コミットする（より正確には、プッシュする）前に検出する必要がある点は重要です。オープンソースプロジェクトでは、CIやプルリクエストのプロセスでテストするのでは遅すぎます。その時点ですでに認証情報が漏えいしているからです。

漏えいした認証情報を無効化する

最後に、鍵やパスワードがすでに漏えいしたとわかった場合は、速やかにトークンを無効化してください。

最新のリリースやブランチからトークンを削除するだけでは不十分です。過去の記録を削除したとしても、GitHubやnpmから削除した後も鍵のコピーは残ります。インターネット上の情報は消えないのです。また、鍵が悪意あるコードの公開やシステムへのアクセスに使われていないか、後から確認することも重要です。

オープンソースの利用者がすべきこと

オープンソースパッケージの利用者にできることは多くありません。パッケージを使うということは、それを明示的に信頼し、同時にその依存関係も暗黙的に信頼することになるからです。依存関係のセキュリティ上の不備は、認証情報の漏えいであれ脆弱性であれ、自社システムを危険にさらす可能性があります（後者への対処にはSnykを利用できます）。ChALKeRによると、彼が発見した認証情報は、それぞれGitHubとnpmによってすでに無効化されています。無効化された認証情報は、悪用されていない限り、もはやセキュリティリスクにはなりません。

とはいえ、先回りして対策したい場合は、依存関係を監査し、本来共有されるべきでないと思われる情報が含まれていないか確認するとよいでしょう。bashのちょっとしたスクリプトで、依存関係にある関連するドットファイルを見つけられます。その後、個人情報が含まれているかどうかを自分で判断できます。

まずは、Mac/Linuxで使える次のbashコマンドを試してください。対象ファイルを検索し、重複を除いて、ファイル名とともに出力します。

find . \( -name '*.gypi' -o -name '.npmrc' -o -name '.travis.yml' \) | xargs md5 -r | sort | awk '{print $2" "$1}' | uniq -f1 | sort | awk '{print "echo "$1";cat "$1}'

まとめ

オープンに開発するのは素晴らしいことですが、すべてを共有すべきとは限りません。認証情報の漏えいは利用者を危険にさらし、ひいてはそのユーザーにも影響を及ぼします。

認証情報をコードから分離し、このリスクを全員が認識して注意を払うようにしましょう。コードレビューで漏えいを確認し、標準的なプラクティスにチェック項目として加えてください。プロセスに加えて、前述の安全策を導入し、人為的ミスを検知できるようにしましょう。最後に、漏えいが判明した場合は適切に対処します。トークンを無効化し、利用者に通知し、コードに悪意ある痕跡がないか調査してください。