|
翻訳者 | 陳俊 校正：孫淑娟 革新的な開発は、コーディング担当者にとってしばしば困難な「試行錯誤」を伴います。GitLabユーザーなら誰でも、DevOpsチームが中断のないワークフローを維持するためにソースコードが重要であることをある程度認識しています。 GitLabは間違いなく最も信頼性の高いソースコード管理（SCM）ツールプラットフォームの一つです。一体何が起こり得るのでしょうか？と疑問に思う方もいるかもしれません。オープンソースプラットフォームであるGitLabは、サービス中断、ランサムウェア、システムクラッシュなど、様々な潜在的な脅威にさらされています。これらの脅威には、GitLabサーバーへの攻撃に起因するものもあれば、GitLabデータベース自体の障害に起因するものもあります。そのため、あなたとあなたのチームは、GitLabデータの堅牢なバックアップメカニズムを確立することで、様々な災害シナリオに常に事前に備える必要があります。同時に、デフォルトのバックアップ戦略がDevSecOpsプロセスとCI/CDパイプラインに統合されていることを確認する必要があります。 GitLab のバックアップには何を含めるべきですか?バックアップ対象のGitLab環境を決定したら、GitLabのバックアップにすべてのGitLabリポジトリとメタデータが含まれていることを確認する必要があります。ここで言う「メタデータ」とは、Wiki、課題、課題コメント、デプロイメントキー、マージリクエスト、LFS（Linux from Scratch、インターネットから直接ソースコードをダウンロードしてLinuxをゼロからコンパイルする手法）、タグ、Webhook、マイルストーン、リリース、オペレーションなど、様々なコンポーネントや側面のバックアップを指します。これらをバックアップすることによってのみ、開発チームやプロジェクト全体で利用されるすべてのGitリポジトリデータを適切に保護することができます。 II. バックアップ戦略の主な特徴ワークフローを明確に理解したら、バックアップ戦略の策定に取り掛かりましょう。ワークフローを中断させないためには、必要に応じて複数のバックアップを実行する必要があります。これにより、GitLabデータのタイムリーな復旧が可能になるだけでなく、監査、コンプライアンス、セキュリティ要件も満たすことができます。考慮すべき重要なセキュリティ要因を以下に示します。
上記は、堅牢なバックアップ戦略に関連する基本的なセキュリティ面のみをカバーしています。GitLab環境の包括的なバックアッププランを策定したい場合は、様々な高度なバックアップ機能を備えた代替バックアップ戦略を検討し、構築する必要があります。 1.3-2-1 バックアップルールDevOpsチームがソースコードに精力的に取り組んでいる場合、GitLabの停止やバックアップの失敗は、彼らの作業をすべて失い、企業に経済的損失をもたらす可能性があります。この問題に対処するために、3-2-1の「黄金律」と呼ばれるバックアップルールをご紹介します。企業は2つの異なるストレージインスタンスに3つのバックアップコピーを保持し、少なくとも1つはオフラインにする必要があります。したがって、ローカルバックアップを複数の場所に保存し、サービスの冗長性と事業継続性を確保するために、バックアップのレプリケーションに注意を払う必要があります。 もちろん、DevOpsバックアップソフトウェアがマルチストレージ対応であれば、ソフトウェアコストを大幅に削減できます。現在、AWS S3、Backblaze B2、Google Cloud Storage、Azure Blob Storage、GitProtect Cloud、そしてS3、オンプレミス、ハイブリッドストレージに対応したその他のパブリッククラウドがこの互換性を提供しています。ご不明な点がある場合は、バックアップサービスプロバイダーにご相談ください。既存のインフラストラクチャを最大限に活用し、コードデータと独自のストレージスペースを複数の保存先にバックアップできるかどうかをご確認ください。 2. 無期限に保持する必要があるデータバックアップを設計する際には、保持期間も重要な考慮事項です。重要なGitLabデータの場合、保持期間は5年、10年、あるいは無期限に設定できます。コードに個人データが含まれている場合は、その保持期間は現地の法律、規制、および共同責任の要件に準拠する必要があります。 3. ランサムウェアからの保護GitLabデータのバックアップは、ランサムウェア攻撃に対する最後の防衛線です。ランサムウェア対策として設計されたGitLabバックアップソリューションは、バックアッププロセス中にGitLabデータを圧縮・暗号化し、保存された状態ではデータが実行不可能な状態であることを保証します。つまり、バックアップデータがランサムウェアに傍受されたとしても、容易に実行されたり、無期限に拡散されたりすることはありません。さらに、最悪のシナリオでは、ランサムウェアが傍受したデータを暗号化、変更、または削除したとしても、バックアップが存在するため、特定の時点で必要なGitLabコピーを簡単に復元でき、チームは遅滞なくプロジェクト作業を継続できます。 4. 監査とコンプライアンスのための監視レポートを提供します。諺にもあるように、情報を持つ者は世界を制する。GitLabのバックアップ自体、バックアップの失敗、バックアップのステータスに関する情報にタイムリーにアクセスできれば、DevOpsチームは遭遇する問題を明確にし、バックアップデータの可用性をリアルタイムで管理することができます。ソフトウェアプロジェクトチームは、Slack通知、データドリブンダッシュボード、メール通知、高度な監査ログなどを通じて、バックアップシステムによって実行されるすべてのアクションを追跡する必要があることがよくあります。この情報はチームにとって有益であるだけでなく、監査やセキュリティ認証のためのバックアップ完了ステータスの詳細なレポートも提供します。 III. 回復プロセスには何を含めるべきか?バックアップ戦略に従ってGitLabの効果的なバックアップを実行することは、全体的な災害復旧計画の一部に過ぎません。GitLabのバックアップデータを可能な限り迅速に復元するための戦略も策定する必要があります。つまり、災害復旧計画は、サービスの中断/ダウンタイム、意図しない人為的ミス、ランサムウェア攻撃によるデータ損失が発生した場合でも、事業の継続を確実に保証するものでなければなりません。 回復戦略を策定する際には、次の点を慎重に考慮する必要があります。
実際には、バックアップと復元の操作を 1 つのアプリケーションに統合できれば、チームの時間を大幅に節約できます。 復旧戦略が確立されたら、GitLab、インフラストラクチャ、バックアップ ソリューションの障害が発生するシナリオにチームがどのように備えることができるかについて話し合うことができます。 1. GitLab で中断が発生しました。 GitLabは信頼性の高いホスティングサービスプラットフォームですが、障害が発生する可能性は依然として存在します。これを解決するには、GitLabインスタンスを.gitファイルとして自分のコンピュータに復元するか、クロスリカバリを使用してGitLabのコピーを別のGitホスティングプラットフォームに直接復元することができます。 2. インフラストラクチャに障害が発生しています。 前述の3-2-1バックアップルールに基づき、インフラストラクチャが中断した場合でも、常に2つの保存先に3つのバックアップコピーが存在し、そのうち1つはオフラインになります。そのため、任意の時点のバックアップコピーを取得し、GitLabリポジトリとそのメタデータを簡単に復元できます。 3. バックアップ ソリューション自体に欠陥があります。 サードパーティ製のバックアップソリューションの利用を決定する前に、潜在的な障害への対応力と、障害発生時に適切かつ信頼性の高いデータ復旧サポートを提供できることを確認することが重要です。例えば、ローカルアプリケーションのインストール時に付与された権限をサードパーティ製バックアップソリューションと共有できれば、SaaS環境に障害が発生した場合でも、ローカルアプリケーションから直接データに簡単にアクセスできます。 IV. 要約まとめると、GitLabの潜在的な障害に対処するには、バックアッププロセスを手動で管理するか、専用のGitLabバックアップスクリプトを作成してスナップショットを作成するか、サードパーティのバックアップソフトウェアの自動バックアップサービスを選択することができます。同時に、災害発生時に実行するリカバリプロセスを設定して、GitLab環境全体へのアクセスを迅速に確保し、チームワークの継続性を確保する必要があります。 元のリンク: https://dzone.com/articles/devops-security-which-gitlab-backup-best-practices 翻訳者紹介:51CTOのコミュニティエディターであるJulian Chenは、ITプロジェクトの実装において10年以上の経験を有しています。社内外のリソースとリスクの管理に優れ、ネットワークと情報セキュリティに関する知識と経験の普及に注力しています。 |
