経緯
冒頭を最初読んだときに、まじで怖かったから、恐怖体験を共有しようと思い、翻訳＆要約した。
あと、githubは、個人開発でよく利用するから、まとめる意義があると思ったから
原文
https://dev.to/gitprotect/github-security-best-practices-15-tips-to-keep-in-mind-2914
翻訳＆要約
ここ数年のGitHubにおけるマルウェアやランサムウェアなどのセキュリティ脅威
- 2019 - トレンドマイクロのマルウェア研究者グループが、SlackとGitHubを悪用する新種のマルウェアを含む水飲み場キャンペーンを発見し、結果的にSLUBと名付けられました。
- 2020年 - GitHubのセキュリティ・インシデント・レスポンス・チームが、オープンソースのJavaプロジェクトを使用している一部のGitHubリポジトリが悪意のあるコードに感染しているとの通知を発表する。
- 2022年4月 - HerokuとTravis-CIに発行されたOAuthアプリトークンが盗まれ、攻撃者が100K npmアカウントのログイン情報を盗み出す。(NPMパッケージがどのように侵害されるかの詳細はこちらをご覧ください)
- 2022年10月 - Checkmarx Supply Chain Securityチームが、攻撃者がリポジトリを制御し、コードやアプリをマルウェアに感染させることができる欠陥に気付く。- 2022年11月 - 脅威行為者が130のコードリポジトリを盗み、フィッシング攻撃で盗まれた従業員の認証情報を使用して同社のGitHubアカウントの1つにアクセスした後、セキュリティ侵害を開示する。
GitHubに認証情報を保存しない DevOpsはいわゆる「秘密」をGitHubのリポジトリに保管する傾向があり、そのリポジトリをチームメイトや会社全体と共有する。データは簡単に漏洩してしまう。
GitHubはこのような場合のセキュリティ対策として、GitHub secret scanningという予防策を用意しています。
GitHubリポジトリ内のすべてのブランチのGit履歴をスキャンし、ユーザー名やパスワードが含まれていることに気づいたら、自動的に機密情報をリセットしてメールで通知してくる。付与されたアクセスの制限と管理 情報漏えいの主な原因の1つは、認証情報の漏えいによるもの。 重要なのは、誰が機密データへのアクセスを許可したのか、ということです。 パスワードの詳細とアクセス権の管理は、常に監視する必要があります。
GitHub チームを使う 開発者、セキュリティ・エンジニアなど、組織のニーズや要件に応じたチームを作り、各チームに適切なアクセス権（管理者、書き込み、読み取りのみなど）を付与する。
２段階認証やMFAを利用する 強力で信頼性の高いパスワードを使っていても、それが破られる可能性があります。 パスワードの強化より２段階認証を使う。 ログインプロセスにおいて、セキュリティ保護の追加レイヤーとして機能する。 GitHubは2要素認証を有効にすることを強く推奨しており、電話へのアクセスができなくなった場合に備えて２段階認証回復コードを提供しています。さらに、GitHubは2023年末までに全ユーザーに2FAの有効化を義務付ける予定です。
個人用アクセストークンと SSH キーをローテーションする 定期的に更新し、パスフレーズで保護したり、ハードウェアセキュリティキーでSSHキーを生成するのも良いアイデア。
コードのブランチ保護を確実にする 内部脅威のリスクを減らし、他方では不要なコードを本番環境に押し込むのを避けるのに役立つ。
GitHub が推奨する対策とセキュリティ機能- 強制的なプッシュと削除を許可する
- 一致するブランチにプッシュできる人のアクセスを制限する。
- ブランチをロックする
- マージする前に、プルリクエストのレビュー、ステータスチェック、会話の解決を確認する。
- 必要な署名付きコミットをチェックする
- リニアヒストリーとマージキューが必要です。
- マージする前にデプロイメントが成功する必要がある
SECURITY.mdファイルの作成をする SECURITY.mdファイルに、プロジェクトのセキュリティの脆弱性について報告するときに従うべき一連のルールを書く。
具体的には、以下の内容を書くといい。- 開示方針：発見された情報について、ユーザーがどのように伝えるべきか、また、その問題に関して誰と連絡を取るべきかという手順を定義するものです。
- セキュリティ・アップデート・ポリシー：発見された脆弱性を他者に伝達するプロセスを定義する。
- セキュリティ関連設定：プロジェクトの展開中にセキュリティ態勢を強化するのに役立つ設定を含む。
- 将来の拡張と既知のセキュリティギャップ：あなたの組織がまだ実装していないいくつかのセキュリティ改善を含む。
フォーキングを無効にする フォークすることによって、セキュリティ追跡のプロセスが遅くなり、少し複雑になる。 ブランチ戦略は無意味になり、つぎ込んだ労力が無駄になる可能性がある。
どのGitHubアプリを入れるか考える CI/CDプロセスの機能として追加するアプリを選択する際には、細心の注意を払うことが非常に重要 ソフトウェアがどの程度安全なのか、すべてのレビューを徹底的に読み、その生産者をチェックし、サードパーティ製アプリにアクセスを許可する前によく考えること
GitHub 環境をバックアップ 定期的なバックアップは、GitHubの停止やランサムウェアの攻撃など、さまざまな不都合な状況に耐えるのに役立つ。
- バックアップするデータ - GitHubのリポジトリとメタデータがすべて含まれていることを確認する。
- ストレージの選択 - データの保存先として、いくつかのバックアップ先を選ぶ価値があります。
- 無制限の保持 - あなたのプロジェクトが永遠に保存されることを保証するものです。
- 3-2-1バックアップルールの実現 - 重要なデータのコピーを2つの異なるストレージインスタンスに少なくとも3つ用意し、そのうちの1つをオフサイトに置くこと。
- ランサムウェア対策 - ソースコードビルドの安全性を確保し、DevOpsチームを強化するための機能セットです。
- 暗号化 - 飛行中および停止中のデータを、独自の暗号化キーで暗号化することが可能です。
- 自動バックアップ
- CI/CDプロセスに実装する。スクリプトを書いたり、定期的にバックアップを実行したりするメンバーをチームに割り当てることができる。GitProtect.ioのようなサードパーティーのソフトウェアを使えば、データのバックアップに責任を持ち、データへのアクセスや復旧を保証することができる。
監査ログでアクティビティを追跡 監査ログを使用して、すべての従業員の活動を随時追跡するのがよい。
監査ログには、誰が、いつ、どのような操作を行ったかという詳細が記録する。レポジトリを定期的にスキャンする 脆弱性やバグを定期的にスキャンする。開発者が新たなセキュリティトラブルを生むのを防ぎ、平和に仕事を進めることに貢献する。
プライベートリポジトリを安全に保管する 組織内で公開リポジトリを使う必要がないのなら、リポジトリを作成できないようにする。
一般にアクセス可能なリポジトリを作成することを防ぐために重要IPアドレスの管理 接続を許可するIPアドレスのリストを構成する。
リモートチームがある場合は、CIDR表記を使用して、各シングルIPアクセスを承認する。
IP許可リストから外れたアドレスは、プライベートリソースにブロックされることが保証される。GitHubにインポートする前にソースコードをチェックする GitHub にインポートする前に、コードの完全な監査を行う。
まとめ
GitHubは便利なgitコード管理システムですが、セキュリティには注意が必要です。
知的財産や資産であるソースコードを保護するために、適切な手順を踏むことが重要です。
GitHubはサービスであり、他のSaaSと同様に共有責任モデルに従って運営されています。
ソースコードのセキュリティはユーザー自身の責任であることを意味します。
DevOpsチームが継続的なコーディングを行うためには、GitHubの数多くの機能を活用し、信頼性の高い安全な環境を構築する必要があります。
感想
SECURITY.mdを作るってのは、初めて聞いた。
これは一般的なのか？と思って調べたら、GitHubの公式で書いてあった。。。
セキュリティスキャンは、してるんだけど、対応が難しい。。。
特定のブランチだけスキャンしたいのだが、いらないブランチは消したほうがいいかな？
認証情報を保存しないのは、結構気をつけてる。
特にAPIキーとかは、気にしてる。
githubのバックアップは、考えになかった。
リポジトリ上にあるから、バックアップ不要でしょ？って思ってたけど、やっぱり必要か。。。
ただ、個人開発としては、不要かなと思う。
アクセストークンの定期更新は、面倒くさいからやる気せんのよな。。。
個人開発だと、リスクが低くなるから、手軽さが問題になってくる気がする。
