チートシート：Bitbucketのセキュリティに関する10のベストプラクティス

このチートシートでは、Bitbucketのユーザーやコントリビューターがセキュリティを強化する方法をご紹介します。Bitbucket固有の内容もありますが、その多くはGitリポジトリにも、Gitを使わないリポジトリにも役立ちます。

チートシートをダウンロード

それでは、Bitbucketのセキュリティに関する10のベストプラクティスを見ていきましょう。まずは、パスワードをBitbucketリポジトリに追加してしまうという、よくあるミスから始めます。

1. Bitbucketに認証情報をコードや設定として保存しない

git-secretsなど、コミットを静的解析できる優れたツールが数多くあります。Gitのpre-commitフックを使って、パスワードや機密情報をBitbucketリポジトリにプッシュしようとしていないか確認できます。機密情報が不適切に保存されていることを示す、設定済みの正規表現パターンにツールが一致すると、コミットは拒否されます。プッシュが少し遅くなることはありますが、その価値は十分にあります。

認証情報をコードとして保存できないよう、チーム全体でルールを設けることは、既存の開発ワークフローにおける不適切な操作を防ぐ効果的な方法です。本番環境でシークレットを管理するには、Vaultのようなツールを活用しましょう。さらに、Keycloak（現在はRed Hatの複数の開発者がメンテナンス）などのID・ユーザー管理ツールチェーンの導入も検討してください。

Atlassianでは、環境変数を使ってBitbucketのプランに認証情報を注入できます。ただし、より安全な方法として、AdaptavistのScriptRunnerをミドルウェアとして使用し、VaultやKeycloakなどの認証情報・認証管理システムに接続する方法があります。

そもそも認証情報をリポジトリに入れない方法は数多くあり、できるだけ多く実践すべきです。それでも機密情報が紛れ込む可能性は常にあります。GitRobやtruffleHogなどのツールを使って、コードベースをパターンマッチングでスキャンし、機密情報を定期的に監査することも検討しましょう。

2. ファイルとBitbucketの履歴から機密データを削除する

Bitbucketリポジトリに機密データが見つかった場合、復旧のためにいくつかの対応が必要です。まず、公開されてしまったトークンやパスワードを無効化します。インターネット上で一度公開されたシークレットは、攻撃者の手に渡ったものと想定し、それに応じて対処してください。

もちろん、リポジトリから同じ機密データを削除する必要もあります。ただし、Bitbucketはすべてのコミット履歴を保持する点にも注意してください。機密情報を記載した変更履歴も含まれます。リポジトリから機密データを削除したら、Bitbucketの履歴も消去することが重要です。詳しくは、リポジトリの履歴からファイルを削除する方法をご覧ください。これはGitHubのリンクですが、すべてのGitリポジトリに共通する一般的なアドバイスなので、Bitbucketでも活用できます。また、ScriptRunnerを使えば、こうしたインテグレーションを簡単に実現できます。

3. アクセスを厳格に管理する

ここイギリスでは、ものすごく暑くなると（と言っても、ほんのり暖かい程度ですが）、サウナ状態にならないよう、家中の窓を開けるのが一般的です。一方、外出するときは玄関の鍵を二重にかけますが、空気を通すために窓は少し開けたままにすることもよくあります。もちろん、これは理にかなっていません。侵入しようとする人は、玄関から入るとは限らないからです。わざわざ開けてある窓をよじ登るなど、もっと目立たない侵入経路を探すでしょう。アプリケーションのセキュリティ対策でも、同じようなことがよく起きます。複雑な攻撃経路には細心の注意を払う一方、最も単純な攻撃には簡単に突破されてしまいます。たとえば、開発者がパスワードを書いた付箋をモニターに貼ったままにするだけで、攻撃者にアクセスされる可能性があります。Bitbucketプラットフォーム上でも一般的な環境でも、基本的な設定と慣行を確実に守る必要があります。コントリビューターには、次の基本ルールを徹底しましょう。

1. すべてのコントリビューターのBitbucketアカウントで2要素認証を必須にする。

2. Bitbucketユーザー間でアカウントやパスワードを共有させない。

3. ソースコードにアクセスできるノートパソコンやデバイスは、適切に保護する。

4. リポジトリ管理者は、チームのデータアクセスを管理する。コントリビューターには、業務に必要なデータだけへのアクセスを許可する。

5. Bitbucketアカウントは個人アカウントの場合があり、ユーザーが会社を退職しても自動的には削除されません。一緒に働かなくなったBitbucketユーザーのアクセス権は、漏れなく取り消してください。

Bitbucketのブランチ権限モデルを使うと、どのユーザーがどのブランチにコミットをプッシュできるかを制御できます。

ScriptRunnerジョブをスケジュールして、指定した日時に特定のBitbucketユーザーを無効化し、Bitbucket Serverへの以後のアクセスを防止できます。次の例では、2018年8月17日午前9時に「User」と「Contractor」を無効化します。「Notes」セクションには、変更を報告した人物を確認できるよう、JIRA課題キー「ACCESS-1234」を記載しています。

4. SECURITY.mdファイルを追加する

ほとんどのプロジェクトオーナーやメンテナーが、リポジトリにREADME.mdを追加するのは自然なことです。実際、今ではREADME.mdを追加するのが当然とされ、ないと厳しく見られることもあります。同様に、プロジェクトのセキュリティ関連情報をまとめたSECURITY.mdファイルを追加することも、ますます一般的になっています。オープンソースプロジェクトのユーザーに重要なセキュリティ情報を提供できるだけでなく、メンテナー自身が脆弱性の報告、アップデート、一般的なセキュリティ対策への対応方法を考えるきっかけにもなります。

SECURITY.mdファイルに記載することが推奨されるトピックの概要を、以下に示します。

脆弱性開示ポリシー

2017年版Snykオープンソースセキュリティの現状レポートによると、公開された脆弱性開示ポリシーを持たないメンテナーのうち、脆弱性について非公開で通知を受けたのはわずか21%でした。一方、公開ポリシーを設けているメンテナーでは73%に上ります。この結果は、報告者がセキュリティ問題を責任ある形で完全に開示するための手順を定めることの重要性を示しています。連絡先と連絡方法も明記しましょう。これにより、プロジェクトのユーザーから重要なフィードバックを得られます。簡単で明確な手段がなければ、対応自体を諦めてしまいがちです。また、修正が提供される前に、脆弱性の存在をオープンな課題として登録してしまい、意図せず世界中に知らせてしまう人もいるでしょう。問題が見つかった際、プロジェクトのメンテナーに適切な情報を伝えられるよう、ユーザーに必要な手順をすべて案内してください。

セキュリティアップデートポリシー

ソフトウェアの脆弱性は毎日のように発見されています。アプリケーションやライブラリに脆弱性が見つかった場合、プロジェクトのユーザーに知らせる責任があります。ユーザーは、本番環境の重要なシステムであなたのオープンソースコードを利用しているかもしれません。脆弱性の深刻度やリスク、修正版への移行方法など、関連情報を共有するための明確なプロセスを用意する必要があります。あらかじめプロセスを定め、新たな脆弱性の発見・修正時に情報がプロジェクトのユーザーへ届き、できるだけ早く最新情報を得られるようにしましょう。セキュリティ用メーリングリストを用意するだけでも構いません。リポジトリ内の情報をまとめる場所として、SECURITY.mdファイルが適しています。ウェブサイトがある場合は、独立したページの作成も検討しましょう。例としてExpress.jsのセキュリティページをご覧ください。

セキュリティ関連の設定

プロジェクトのセキュリティ対策は、コードだけにとどまりません。オープンソースプロジェクトのユーザーは、利用環境で正常に動作させるために、プロジェクトへの設定追加や各種設定の作成が必要となる場合があります。プロジェクトをデプロイする際のセキュリティを強化するために、推奨設定をユーザーに提供しましょう。たとえば、HTTPSの有効化、認証レイヤーの追加、デフォルトパスワードの変更などです（MongoDBユーザーの多くが「事前に知っておきたかった」と思うアドバイス）。多くのユーザーはセキュリティに関する知識が十分ではないことを念頭に置き、役立つ情報を積極的に提供しましょう。

既知のセキュリティ上の課題と今後の改善

ユーザーが環境を保護するために必要な情報を提供することと、攻撃者に攻撃経路を教えてしまうことにはトレードオフがあります。共有する情報が双方にどう利用されるか、常に考慮してください。必要なセキュリティ改善がすべて実装済みのプロジェクトは、ほとんどありません。現時点で実装されていないセキュリティ対策を、プロジェクトのユーザーに知らせることが重要です。ユーザーには、プロジェクトの利用方法について十分な情報に基づいて判断できるよう、全容を知る権利があります。改善項目をリストに載せれば、ユーザーからセキュリティ対策の実装に貢献してもらえるかもしれません。

5. Code Insightsでワークフローにセキュリティのヒントを取り入れる

Code Insightsは、プルリクエストに関連する情報を提示し、作成者やレビュー担当者がより多くの情報に基づいて判断できるように設計されています。Snykは、オープンされたすべてのプルリクエストをスキャンするインテグレーションを提供しています。新たなオープンソースの脆弱性が持ち込まれていないか確認し、脆弱性が含まれている場合はプルリクエストのマージをブロックできます。

新たな脆弱性が見つかると、Snykが通知し、脆弱性を修正するためのアップグレード案やSnykパッチを含む修正プルリクエストを作成します。

Bitbucketのプルリクエスト画面では変更内容がスキャンされ、新たな問題につながる変更の横に、詳細なインライン注釈として結果が表示されます。こうした注釈により、Snykのスキャン結果を理解しやすくなり、情報に基づいた判断ができます。

インストール方法と使い方の詳細は、実際の動作を動画で紹介するこちらのSnyk Bitbucket Code Insightsブログ記事をご覧ください。

6. Bitbucketアプリケーションを慎重に検証する

優れたプラットフォームは拡張できるものです。アプリマーケットプレイスを備えたBitbucketも例外ではありません。アプリケーションは組織やサードパーティの開発者が作成しているため、リポジトリに追加する際はこの点を考慮しましょう。Bitbucketアプリケーションを選択・インストールするときは、次の点を検討してください。

• アプリケーションに、必要以上のアクセス権を与えない。

• アプリケーションが要求するアクセスレベルが必要な理由を確認し、その権限でどのような被害が起こり得るかを検討する。

• プロジェクトに新しいコミッターを迎えるときと同様に、リポジトリへのアクセスを許可する前に、アプリケーションの作成者や提供組織が正当で信頼できることを確認する。

セキュリティは最も弱い部分のレベルに左右されます。アクセスを許可したアプリケーションのセキュリティ対策が不十分だと、そのコードが侵害された際に攻撃者があなたのコードにもアクセスできてしまいます。コードは最も機密性の高い資産の一つです。

最後に、アプリケーションとそのコントリビューターを定期的に監視・監査し、引き続き必要か、信頼できるか、求めるアクセス権を与えるに値するかを確認してください。アプリケーション管理を怠らず、不要になったものや、許容できない権限を要求するものは削除しましょう。

7. プルリクエストにセキュリティテストを追加する

Bitbucketには、イベント駆動型の強力なGit Hookフレームワークがあり、イベント発生時に任意のサービスへHTTP POSTリクエストを送信できます。対応するイベントは数多くありますが、コードの変更分をテストするうえで特に役立つのがpull_requestイベントです。Git Hookに対応した静的コード解析ツールは数多くあり、PRが作成されるとHTTP POSTを送信して、最新の変更をテストできます。コードや設定の変更がセキュリティ要件に沿っているかを確認するのに最適なタイミングです。

たとえばSnykは、リポジトリを静的解析し、使用している可能性のある脆弱な依存関係を検出して、その修正を支援します。SnykのUIでリポジトリをテストして問題を見つけられるだけでなく、プルリクエストをテストし、新たな脆弱性が持ち込まれた場合にテストを失敗させることで、開発者が脆弱なライブラリを追加するのを防げます。

Bitbucketとの連携が便利なだけでなく、プルリクエストは「ビルドを止める」方法よりも優れています。マージをブロックする必要がなく（実際、デフォルトでは情報提供のみです）、変更後の結果だけでなく変更内容自体をテストできるからです（たとえば、既存の脆弱なライブラリではなく、新たに脆弱なライブラリを追加した場合にのみ失敗させられます）。

Snykに加えて、セキュリティコードレビューを自動化するためにSonarCloudやCodeClimateの利用も検討しましょう。また、リポジトリにシークレットをプッシュしないようにするため、ScriptRunnerスクリプトの追加も検討してください。

8. Bitbucket Pipesでセキュリティテストを追加する

Bitbucket Pipesを使うと、すぐに使えるタスクを組み合わせてCI/CDワークフローをカスタマイズし、自動化できます。Snykはすぐに使えるPipeを提供しており、継続的インテグレーション／継続的デリバリー（CI/CD）ワークフローの一環として、アプリケーションの依存関係とDockerイメージをスキャンし、既知のオープンソースのセキュリティ脆弱性を検出できます。

Snyk Pipeをワークフローに追加するには、Snyk Pipeをコピーしてパイプラインに貼り付けるだけです。

Bitbucket Pipelineのワークフローに追加すると、Snyk PipeはCI/CDワークフローの一環として依存関係をスキャンし、オープンソースの脆弱性を検出します。脆弱性が見つかった場合、事前に設定した内容に従ってプロセスを制御します。たとえば、深刻度の高い脆弱性がビルドに進むのを防ぎます。詳しくはドキュメントをご確認ください。

セキュリティのレジリエンスを高めるために、パイプラインへの追加を検討すべきもう1つのPipeはSonarCloudです。

9. セキュリティ要件に合ったBitbucketのプランを選ぶ

プロジェクトや組織の規制によっては、ローカルでのみ実行できるソフトウェアに制限される場合があります。また、ソースコードの保存場所や、アクセスを許可できる他の組織が制限されることもあります。金融機関、政府機関、その他の厳しく規制された業界では、よくある制約です。しかし、だからといってBitbucketを利用できないわけではありません。

組織内でBitbucketリポジトリを完全にホストできる、オンプレミス版Bitbucket Serverをご覧ください。インターネットから切り離された環境でも、Bitbucket Serverのリポジトリにあるプロジェクトへ社内からアクセスできます。

10. SSHキーと個人用アクセストークンをローテーションする

Bitbucketへのアクセスには通常、SSHキーまたは個人用アクセストークンを使用します（2要素認証を有効にしているため、パスワードの代わりに使用します）。しかし、トークンが盗まれたことに気づかなかったらどうなるでしょうか。キーやトークンを定期的に更新し、流出したキーによる被害を抑えましょう。

Bitbucketのセキュリティについてさらに知るには、Bitbucketのセキュリティアドバイザリもぜひお読みください。まだダウンロードしていない場合は、今すぐこのチートシートをダウンロードして目につく場所に貼り、今後も安全な判断を下せるようにしましょう。