異なる学問分野が統合されてプロセスを効率化することができるのは興奮します。 2009年、DevOpsは開発と運用チーム間の摩擦に対処するために作られました。その結果、業界は両チームを結びつける方向に進み、開発チームがコードの記述から本番展開まで全サイクルに責任を持つこととなりました。もちろん、開発した人々よりも複雑さをよりよく理解する人はいません。
この移行の後、機能が急速に提供されるようになり、新機能の市場投入時間も急速に短縮されています。DevOpsはまた、MLOps、DataOps、GitOpsなどの他の多くの実践の基盤として機能し、疑いなく多くの実践が登場しました。
今日は、皆さんがよく知っているかもしれないDevSecOps（Development Security Operations）と呼ばれる実践についてお話しします。では、DevSecOpsとは何でしょうか？
セキュリティは伝統的に二の次に扱われ、チームが最初に機能を本番環境に提供し、その後セキュリティの問題対処を急いでセキュリティレビューやインシデント中に展開していました。サイバーセキュリティ、サプライチェーン、およびその他の高度な攻撃の急増に伴い、業界は開発と運用と同様に、セキュリティもプロセスの一部であるべきだと迅速に認識しました。セキュリティはできるだけ早い段階で開発ライフサイクルに組み込まれるべきであり、後でセキュリティに対処することは（アーキテクチャおよび運用の観点から）高コストになる可能性があります。
今、開発ライフサイクルのさまざまな段階でそれを適用する方法について議論しましょう。それにより、出荷するコードが効率的であるだけでなく、安全であることが確認されます。
通常、機能を出荷するプロセスには以下が含まれます：
- 開発 – 機能を構築
- 配布 – アーティファクトが作成され、配信の準備が整えられます
- 展開 – 機能がリリース され、本番環境にデプロイされます
開発段階で、開発中の機能のセキュリティ姿勢を向上させるために取るべき手順について議論しましょう。
開発段階では、機能は設計レビュー、コーディング、そしてプルリクエストのレビューを経ます。設計レビューの一環として、機能所有者はAPI契約の外観、使用しているデータベースの種類、インデックス付け、キャッシュ戦略、ユーザーエクスペリエンスなどについて議論します（これは完全なリストではありません）。セキュリティ志向の文化では、脅威モデリングも重要です。
脅威モデリングを実行する
単純に言えば、 脅威モデリングは、「脆弱性の特定、リスク評価の実施、推奨される緩和策の実装を行うプロセスであり、製品/組織のセキュリティポジションが損なわれないようにする」ことです。」
これを理解するために例を挙げてみましょう。以下のAPIを開発していると想像してください:
- 製品カタログ内の製品をリストします。
- 製品または製品タイプを検索します。
GET /api/products?search=laptop
脅威モデルは次のようになります:
| functionality | vulnerability | risk assessment | recommended mitigation |
|---|---|---|---|
| 認証されていないユーザーが製品を検索できます | 脅威行為者がDDoS（分散型サービス拒否）攻撃を行う可能性があり、データベースとAPIインフラを圧倒する | ハイ – サービスを停止させ、可用性を低下させる可能性があります | DDoS攻撃を防ぐためにAPIゲートウェイまたはレート制限装置を使用します。 |
| ユーザーが検索フィールドにクエリ文字列を入力します | SQLインジェクション攻撃を行う可能性があり、”1=1″を挿入します | ハイ – 攻撃者が本番テーブルを削除できます | 入力値に適切な検証/サニタイズが行われていることを確認します。 |
| ユーザーは製品の詳細を受け取ります | 内部フィールドの公開、データベースID、ステータスコード、およびバージョン番号などは、攻撃者にデータベースや基礎システムの構造に関する重要な情報を提供する可能性があります。 | 中程度 – 攻撃者はこれらの内部実装を使用して情報収集などの攻撃を行うことができます。 | ユーザーに必要な詳細のみを送信してください。 |
これらは製品のエンドポイントを見る際に考えられる点です。最高の部分は、セキュリティ専門家である必要はないということです。これらの脆弱性を認識するのに。セキュリティの専門家である必要はないということです。
Microsoft Threat ModelingツールやOWASP Threat Dragonsなどのツールを使用してこれらを特定することができます。
Microsoft Threat Modeling Toolにおける脅威モデルの例
分析ビュー
脅威モデリングツールの分析ビューには、APIに発生する可能性のある異なる攻撃が表示されます。
チームと一緒に脅威モデルを見直すことは、可能な限り多くのセキュリティのギャップを特定し緩和するためのブレインストーミングセッションとして機能することができます。
- 弱い暗号利用。たとえば、SHA1やMD5の使用は弱いと見なされます。CA530は、コード内で弱いハッシュ関数が使用されている場合にC#が警告を生成する例です。
- SQLインジェクション攻撃。 CA2100は、コードがインジェクション攻撃に対して脆弱かどうかをチェックする例です
- ハードコードされたパスワード、弱い認証および認可メカニズム、および インフラストラクチャの誤構成は、静的解析ツールで検出できます。
この領域には既存のツールもあります。SonarQube、CodeQL、Roslyn Analyzer、OWASP Dependency Check、および Snykはこの分野で優れた製品を提供しています。some
ビルドパイプラインに静的解析を統合することも重要です。次のような利点があります：
- 開発者にとって一貫した脆弱性検出体験を提供します。
- サービスのセキュリティポジションを向上させます。すべての本番展開はこれらの手順を経る必要があるため。
セキュリティの観点からのコードレビュー
通常、コードレビューはバグの特定とベストプラクティスの確保に焦点を当てますが、セキュリティの観点からも評価することが重要です。各プルリクエストのセキュリティの影響を考慮することで、将来の脅威を予防し、アプリケーションの完全性を保護できます。as well。
結論
結論として、サイバーセキュリティの状況がますます高度化する中で、セキュリティを最後に任せるのではなく、初期段階で考慮することが重要です。その一環として、脅威モデルの構築と自動静的分析を定期的な開発サイクルに組み込んでください。
次回の記事では、配布時に取り入れられるセキュリティプラクティスについて、コンテナイメージのスキャン、動的アプリケーションセキュリティテスト(DAST)、およびサプライチェーン攻撃からサービスを保護するためのアーティファクト署名を含めて議論します。
Source:
https://dzone.com/articles/building-security-into-design-phase