ベストプラクティス

新しい DevSecOps メカニズムを実装するときは、コード作成者のさまざまなソースと、それらがどのように権限を付与されるか、またはブロックされる可能性があるかを考慮することが重要です。多くの場合、エンジニアはこれらのソースのいずれかとのみインターフェイスできます。ただし、新しいメカニズムの導入により、新しいオーサシップソースを前面に出し、以前に考慮されていないソースの課題を強調することができます。以下の各側面について詳しく見てみましょう。

• アプリケーションチームのデベロッパー – これらは、コアアプリケーションコードを担当するデベロッパーです。必要に応じてアプリケーションコードを変更および更新する権限が必要ですが、その作業も新しい DevSecOps メカニズムと一致する必要があります。

• 中央インフラストラクチャ開発者 – このチームは、クラウドリソース、ネットワーク、セキュリティなど、組織のコアインフラストラクチャを担当します。新しいメカニズムがシームレスに統合されるように、Infrastructure as Code (IaC) とデプロイプロセスの定義に関与する必要があります。

• サードパーティーおよびオープンソースのコードベース – サードパーティーのライブラリとオープンソースコンポーネントの使用が一般的です。ただし、これらのソースは、新しい DevSecOps メカニズム内で慎重に管理および保護する必要があります。

• 再利用可能なコードとアーティファクト – 再利用可能なコードとアーティファクトの作成と使用を促進することで、効率と一貫性を向上させることができますが、これらの共有リソースの所有権とガバナンスを明確に定義する必要があります。

• 共有リポジトリとコントリビューション – 共有リポジトリを通じて共同コードオーサシップを有効にすることは有益ですが、品質とセキュリティを維持するためには、アクセス、マージポリシー、コードレビューを慎重に管理する必要があります。

• IaC の分岐戦略 — Git 手法は、一般的なインフラストラクチャ設計パターンと直接互換性がありません。インフラストラクチャを管理するという固有の課題に対応するために、従来の分岐戦略を IaC に適合させる必要がある場合があります。これには、インフラストラクチャのステートフルな性質、ドリフトの可能性、ライブ環境を変更する際の慎重な調整を考慮した特殊なワークフローの開発が含まれる場合があります。

• 状態管理 – IaC では、インフラストラクチャの状態を管理することが重要です。適切な状態管理により、実際のインフラストラクチャが定義されたコードと一致し、競合や意図しない変更を防ぐことができます。リモートステートストレージやステートロックメカニズムの使用など、堅牢なステート管理プラクティスを実装することは、一貫性を維持し、マルチユーザー環境での競合を防ぐために不可欠です。

• セキュリティ - IaC と DevSecOps のコンテキストでは、インフラストラクチャライフサイクルのすべての段階でセキュリティを統合する必要があります。これには、IaC コードベース自体の保護、最小特権のアクセスコントロールの実装、機密データの暗号化、インフラストラクチャコードとデプロイされたリソースの両方の脆弱性の定期的なスキャンが含まれます。セキュリティのベストプラクティスが一貫して適用されるように、自動化されたセキュリティチェックとコンプライアンス検証を継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに組み込む必要があります。

さまざまなチームに効果的に権限を与えてサポートする DevSecOps メカニズムを設計するには、コード作成者の潜在的なソースをすべて特定し、そのニーズと課題を理解する必要があります。このアプローチは、組織全体で新しいメカニズムのスムーズな実装と導入を確保するのに役立ちます。

DevSecOps メカニズムの設計は、単なる技術的側面にとどまりません。DevSecOps メカニズムの設計と実装には、広範な影響があります。責任を負うチームは、文化的、組織的、人的要因を慎重に検討する必要があります。この考慮事項は、ソリューションが技術的な要件を満たすだけでなく、すべての利害関係者にとってポジティブで生産的で魅力的な作業環境を促進するのに役立ちます。適切なバランスを取ることは、長期的な成功と従業員の満足度にとって不可欠です。

DevSecOps メカニズムの設計とデプロイに関連する以下のシナリオを検討してください。

• デベロッパーとメンテナーの格差の拡大 – 熱心なデベロッパーがソリューションを迅速に提供できるようにするシステムを実装すると、メンテナーの明らかな作業不足が誤って浮き彫りになる可能性があります。メンテナンス担当者はデベロッパータイトルを持つ個人ですが、day-to-dayは既存のアプリケーションのサポートと安定性に移行しています。メンテナンス担当者の新しい貢献の欠如は、これまであまり見られなかった可能性があります。この状況により、組織はこれらの保守者の重要な知識と専門知識を過小評価し、憤慨や士気の低下を引き起こす可能性があります。

• 過度に管理されたソリューションでデベロッパーをリピートする – 管理の厳しい DevSecOps ソリューションを構築すると、デベロッパーが使い慣れるのが面倒になります。ただし、このソリューションは、組織がイノベーションを推進するために必要な人材を遠ざける可能性があります。開発者がアプリケーションやプログラミング言語に加えて独自の CI/CD メカニズムを学習することを強制することは、導入の大きな障壁となる可能性があります。高度に管理された DevSecOps ソリューションは、有能な開発者にとって無関心になる可能性があります。

• 文化的非互換性と混乱のリスク – 組織の既存の作業方法と文化的に互換性のない DevSecOps メカニズムを実装すると、大きな摩擦と抵抗が生じる可能性があります。メカニズムのアプローチ (例えば、アドバイザリと比較した規範的) が組織の文化と一致しない場合、採用されない可能性があります。その結果、一部の利害関係者は不満を抱き、組織が不要な行政機関に移行していると考えている可能性があります。