これまで、組織がより多くの情報を処理したことはありませんでした。 この懸念はすべてのデータに当てはまりますが、特にプロセスの実行を維持するために依存するソースコードに当てはまります。
企業も個人も同様に、GitHub、GitLab、BitBucketなどのプラットフォームを利用して、ソースコードを保存および管理し、開発プロジェクトを実行し続けています。 これらのプラットフォームは非常に人気があります：GitHub 以上 73万人の開発者と200億人のリポジトリ、GitLab 見積もり 30万人の登録ユーザーとBitBucket 報告 10年のユーザー数は2019万人。
セキュリティチームがこれらのプラットフォームに保存されているソースコードについて心配していない場合は、開発者が少なくともいくつかのプロジェクトを保持している可能性があるためです。 近年のいくつかの攻撃は脅威を浮き彫りにしました：2019年のランサムウェア攻撃 拭い プラットフォーム間でソースコードリポジトリをGitし、身代金要求に置き換えました。 GitHubの場合のように、ダウンタイムのリスクもあります ダウンしました 2020年XNUMX月に少なくともXNUMX時間。
Netenrichの主要な脅威ハンターであるJohnBambenekは、ソースコードを失うコストは高いと言います。
「組織にとって重要なものはすべてバックアップする必要があります」と彼は言います。 「経験則として、 『会社はこれなしで事業を継続できますか？』 答えが「いいえ」の場合は、バックアップ計画が必要です。」
企業がソースコードのバックアップを考えていない理由はたくさんあります。 一部はお金を節約したいと考えており、一部はソースコードを危険にさらす攻撃に対して無防備であると感じている可能性があります。 また、バックアップには具体的なメリットがなくてもコストがかかるという現実もあります。必要になるまで、GitLabのシニアセキュリティエンジニアであるMarkLoveless氏は述べています。
「ほとんどの場合、すぐに利益が得られないようなことをしているだけです」と彼は言います。 「それがバックアップのやり方です。 すべてがうまくいくことを望んでおり、バックアップに頼る必要がないため、すぐに利益が得られることはなく、バックアップですぐに利益が得られることを望んでいません。 しかし、そのための計画が必要です。」
意識は別の問題です。 一部の人々は、彼らがそうする必要があるとは思わないので、彼らのソースコードをバックアップしないかもしれない、と彼は付け加えます。 GitLab、GitHub、およびBitBucketは、主要なクラウドプロバイダーと同様に、サービスのユーザーとプロバイダーが情報を保護する責任を共有する「共有責任モデル」を備えています。
GitLabは、「ほぼ常に」独自のサーバーでバックアップを実行しますが、多くの人は、独自のプライベートクラウドスペースまたはデータセンターの物理サーバーでGitLabの独自のインスタンスを実行しています。 このような場合、ユーザーは、使用しているクラウドプロバイダー、保持しているバックアップの種類、およびデータをバックアップする距離を検討する必要があります。
「Git…コードチェックインの履歴が保存されており、以前のバージョンのコードにロールバックできるため、[ユーザー]はバックアップがあると考える傾向があります」とLoveless氏は言います。 「リビジョンとコードの変更に関しては…しかし、それらはデータベース[および]データファイルに保存されており、バックアップする必要があります。」
各コンピューター上のリポジトリの作業コピーは、通常はソースコードのみが含まれ、それに関連する問題、コメント、プルリクエスト、およびその他のメタデータは含まれないため、バックアップとは見なされません。 nVisiumのシニアアプリケーションセキュリティコンサルタントであるTaylorGulleyは、Gitリポジトリまたは他のバージョン管理で十分であると考えるのが一般的です。 バージョン管理は非常に便利ですが、コードは一元化された単一の場所にしか保存されません。
「ディザスタリカバリ計画が開発者のローカルマシンからコードをプルすることでない限り、サーバーをダウンさせたインシデントを乗り切るものがあると仮定すると、適切なバックアップが重要です」とガリー氏は言います。
プロセスについて企業が知っておくべきこと
ソースコードのバックアップには複数の形式があります。 組織は、独自のバックアップを管理し、関連するインフラストラクチャ、プロセス、および修復コストの所有権を取得することを選択できます。 これにより、データをより細かく制御できますが、メンテナンスにリソースが費やされるため、長期的にはコストが高くなる可能性があります。
手動バックアップには、技術的な課題も伴います。 各ベンダーには独自のAPI、プロセス、コメント、問題があるため、すべてのアセットの一貫性を維持してGitリポジトリにリカバリできるようにすることは困難です。 APIリクエストのレート制限には、別の障害があります。通常、GitバックアップはGitプロバイダーのAPIに多くのリクエストを送信することに関連しており、限られた期間に送信されるリクエストの数を制限する必要があります。
または、バックアップ管理を処理するサードパーティに問い合わせることもできます。 多くの場合、これを支援できるクラウドサービスがあります、とBambenek氏は述べています。 組織は、GitHub、GitLab、およびBitBucketのコードをバックアップするように設計されたツールであるGitProtect.ioなどのサービスを利用する場合があります。
「必要性は自社内で見つかりました」と、GitProtect製品開発マネージャーのGregBak氏は製品の作成について述べています。 「これらのリポジトリを保護するための内部スクリプトがいくつかありましたが、これらのリポジトリを常に復元できること、適切に保護されていること、バックアップがテストされていることを保証することはできませんでした。 そこで、それを[構築]することにしました。」
GitProtectは、サービスとしてのバックアップとオンプレミスのXNUMXつのモデルで利用できるため、組織はGitProtectをローカルにインストールすることも、パブリッククラウドにデプロイすることもできます。 この製品の目標は、ソースコードだけでなく、コメント、問題、CI / CDタスクなど、リポジトリの一貫性を維持するために必要なすべての関連メタデータも保護することです、とBak氏は言います。
リポジトリを標的とした攻撃やこれらのプラットフォームの潜在的な混乱以外にも、ソースコードを危険にさらす可能性のある脅威がいくつかあります。 人為的エラー、およびコード自体への不要な変更により、プロセスをバックアップして実行するためにバックアップが必要になる可能性があると彼は付け加えています。
バックアップのベストプラクティス
ソースコードのバックアップ方法に関係なく、GitLabのLovelessは、セキュリティの専門家を部屋に連れてくることをお勧めします。
「何人かの警備員に投資してください」と彼は言います。 「そこに人がいて、これを行う方法を知っている経験豊富な人がいて、人に投資すれば、はるかに良い結果が得られるはずです。」
専門家はまた、バックアップを安全な場所に保存し、暗号化しておくことをお勧めします。 マルチクラウド環境を実行している場合は、バックアップをオフサイトまたはオフシステムにローテーションします。 ガリーは、場所が危険にさらされた場合に備えて、XNUMX枚のコピーをオンサイトに、XNUMX枚をオフサイトに保管することをお勧めします。 以前のバックアップは、自動バックアッププロセスまたはアカウントによって変更または削除できないようにする必要があります。
すべての専門家は、ソースコードのバックアップを作成するだけでは不十分であることに同意しています。 それらをテストし、機能することを確認することも重要です。 そうでない場合は、いつ必要なのかを知りたくありません。 バックアップにアクセスして使用するプロセスをテストして、バックアップを使用できること、および攻撃、停止、または侵害が発生した場合の関係者全員がバックアップの役割を理解していることを確認します。
