DevSecOpsを学ぶ

第8章. DevSecOpsを超えて

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

DevSecOpsに関する本の内容を決めることは、むしろDevSecOpsに関する本に何を書いてはいけないかを 決めることである。第一の問題は、「DevSecOps」という言葉そのものだ。文脈だけでなく、経験や組織の必要性によっても、人によって意味が異なる。テクノロジーは、成功のための真のレシピが利用可能な点まで成熟していない。従うべきパターンや使用すべき技術の断片はある（ここで説明する）。しかし、何をどこに入力すべきかという正確な詳細は、規定することは不可能だ。重要なのは、DevSecOpsは最終ゴールではなく、ソフトウェアデリバリーをより速く、より信頼できるものにする新技術が利用可能になるにつれて進化する、反復的な改善プロセスであるということだ。

DevSecOpsパターン

このセクションは、DevSecOps へのパスであろうと、成熟した DevSecOps SDLC を使っていようと、組織がたどった成功のいくつかのパターンを含んでいる：

• CI/CDへの左シフト

• 冗長性のためのマルチクラウドのデプロイ

• デプロイ後の安全保障はあまり重視されず、安全保障は左遷され、自動化される。

• Linux、特にGUIではなくコマンドラインベースだが、その他のスタックは互換性がある

• トラブルシューティングと最適化はあまり重視せず、リファクタリングと再デプロイに重点を置く。

まずはCI/CDへの左シフトについて説明しよう。

左シフトとCI/CDの追加

継続的インテグレーション／継続的デプロイ（CI/CD）は、まさにDevSecOpsの究極の目標である。開発者はコードを書き、そのコードが本番環境に向けていくつかのゲートを通過することができるはずだ。真のCI/CDを実現するには、パイプラインを大幅にカスタマイズする必要がある。

Argo CDのようなソフトウェアは、DevSecOpsを念頭に置いて設計されている。Argo CDには、可視化を支援するグラフィカルなコンポーネントがあるが、KubernetesやHelmなど、前の章で取り上げたツールを活用するモダンなバックエンドもある。Argo CDをそのまま活用することも、よりモダンなパイプラインを構築するための情報源として活用することもできる。

マルチクラウドの統合

コンテナ化は、この記事を書いている時点では、DevSecOpsにおける技術の現状 である。AWS、Google Cloud、Azureの3つの主要なクラウドプロバイダーはすべて、Kubernetesとうまく統合するコンテナ化を提供しており、Google Cloudはその歴史からKubernetesとの親和性が高いことに注目している。クラウドでのコンテナとワークロードの実行はシームレスであるべきで、組織は必要性、地理的需要、または冗長性に基づいて、3つのクラウドプロバイダーのいずれかにデプロイできる。

統合された自動セキュリティ

適用が難しかったり、使いにくかったりするセキュリティ対策は実装されない。成功するDevSecOps 「デフォルトで安全である」だけでなく、控えめなセキュリティも重視する。ロールベースのアクセス制御は、ユビキタスな方法で使用される。本稼働後にセキュリティ問題を発見することは、攻撃者がまだその問題を発見していないと仮定すれば、良いことである。しかし、本稼働後にセキュリティ問題を発見するのは最適ではない。スキャンツールは本番後に必要だが、セキュリティは左遷され、自動化される必要がある。 ...