Blog

この場合、アジャイルにSecured Delivery Lifecycle（SDLC）を適応させる主な動機は、開発された製品のセキュリティを強化することです。これには通常、セキュリティ上の欠陥の数を減らし、セキュリティ上の欠陥の重大度を減らすことが含まれます。また、プライバシーの問題は重要であり、SDLC forAgileプロセスで処理されます。

スクラム

アジャイルスクラム手法は、製品開発を管理するための反復型および増分型のアジャイルソフトウェア開発フレームワークです。基本的なスクラムイベントは次のとおりです。

• スクラム計画-スプリントバックログを定義するために、各スプリントの開始時に開催されます。
• スクラムグルーミング–製品の所有者は、開発チームと協力して、ユーザーストーリーと設計上の決定を詳しく説明します。
• スプリント-2週間のタイムボックスで、「完了」、使用可能、および潜在的にリリース可能な製品増分が作成されます。
• デイリースクラム-チームがステータスを簡単にチェックするためのデイリーミーティング。
• スプリントレビュー–チームが製品をデモンストレーションし、結果が製品の所有者と顧客の期待どおりであることを確認するイベント。

安全な開発ライフサイクルをアジャイルスクラムにマッピングする

アジャイル手法にセキュリティをうまく採用するために、次の要件を満たそうとしました。

• セキュリティは、アジャイルソフトウェア開発方法に適応する必要があります。
• セキュリティは、開発のすべての段階で具体的なガイダンスとツールを提供する必要があります。
• セキュリティアプローチは単純でなければなりません。開発プロジェクトの妨げになることはありません。
• 最も重要なSDLCアクティビティ（設計モデリング、セキュリティレビュー、セキュリティテスト、自動化、静的コード分析）は、適切なSCRUMフェーズで実装する必要があります。

要件-トレーニング

すべての開発チームメンバーは、安全なコードの記述、セキュリティコードのレビュー、およびセキュリティテストの実行に焦点を当てた独自のセキュリティトレーニングに参加する必要があります。

デザイン– STRIDEモデル–グルーミング、計画

すべての機能について、次の質問をします。

• この機能はなりすましの影響を受けやすいですか？
• この機能は改ざんできますか？
• 攻撃者はこのアクションを拒否できますか？
• 攻撃者は、この機能を攻撃することにより、情報への不正アクセスを取得できますか？
• 攻撃者はこの機能またはデータフローへのサービスを拒否できますか？
• 攻撃者はこの機能を攻撃することで特権を高めることができますか？

次の表に、セキュリティの原則と、各STRIDEフラグメントに関連する対策の例を示します。

セキュリティの原則を設計する

攻撃対象領域を最小限に抑える

すべてのコードには、欠陥が含まれている可能性があります。コードが多いほど、アプリケーションに欠陥がある可能性が高くなります。より多くの欠陥がある場合、アプリケーションの攻撃対象領域が増加します。設計段階では、次の方法で攻撃対象領域を減らすことに重点を置きます。

• パブリックアクセスの最小化-KenticoCloudリソースを保護するための適切なアクセス制御メカニズムの実装。
• コードの量を減らす-未使用のコードを削除する
• 他の原則に従う–次のセクションを参照

安全なデフォルト

当社の開発者は、除外ではなく許可に基づいてアクセスを決定します。これは、デフォルトでアクセスが拒否され、保護スキームがアクセスが許可される条件を識別することを意味します。

例：

機能に認証が必要な場合->デフォルトでACLの小さなサブセットのみを付与します。

多層防御を使用する

多層防御の原則は、階層化されたセキュリティメカニズムがシステム全体のセキュリティを強化することです。攻撃によって1つのセキュリティメカニズムが失敗した場合でも、他のメカニズムがシステムを保護するために必要なセキュリティを提供する可能性があります。

例：

SQLインジェクションに対する保護は、いくつかの対策で構成されます。

• 適切な入力検証
• プリペアドステートメントの実装
• 権限に関してDBサーバーに最小特権レベルを適用する
• DBトランザクションのロギング/モニタリング

最小限の特権を使用する

最小特権の原則は、通常の機能を可能にする最小限のレベルにアクセスを制限することです。

例：

SQLサーバーを保護するために、最小特権の使用をどのように実装できますか？

• SQLアカウントをユーザーdb_ownerにしないでください
• 特定の権限のみを付与する
• SQLサーバーでxp_cmdshellを無効にする

非常に類似したアプローチがファイルシステム構成などに適用されます。

間違いから学ぶ

完璧な人は誰もいませんし、時には間違いを犯します。コードに脆弱性が見つかった場合は、すぐに適切なアクションを実行します。調査プロセスの一環として、私たちはいくつかの質問をします。

• セキュリティエラーはどのように発生しましたか？
• 同じエラーがコードの他の領域に複製されていますか？
• このエラーの発生をどのように防ぐことができたでしょうか。
• この種のエラーが将来発生しないようにするにはどうすればよいですか？

ステップバイステップ–脆弱性が特定され、同じ/類似の問題が含まれていない場合はソリューション全体が分析され、コードの改善が実装されます。たとえば、新しいテストの作成、同様の問題についてソリューションをスキャンする新しいカスタムスクリプトの作成、またはベストプラクティスの作成実践。

実装-スプリント

新しい機能が実装される各反復サイクルで、開発者はセキュリティトレーニングコースで学んだ知識を活用します。実装とコードレビューは、OWASPによる上位10の脆弱性をカバーするだけでなく、ビジネスロジックのセキュリティ問題も探します。

当社のセキュリティチームは、セキュリティの問題が発生した場合に迅速なフィードバックを得るために、すべての重要なアクティビティを自動化します。自動化されたアクティビティ：

• REST API（バックエンド）は、自動化されたWeb脆弱性スキャナーを使用して毎日定期的にスキャンされます。
• 新しいパブリックエンドポイントまたは内部エンドポイントが作成されると、カスタムツールがチームに変更を通知します。

セキュリティチームは、すべての新しいエンドポイントを手動でレビューして、コードが開発者によって適切にレビューされ、セキュリティの問題が含まれていないことを確認します。

検証–レビュー

最終的なセキュリティレビューは、新機能に関連するすべてのセキュリティの側面が考慮されていることを確認するのに役立ちます。新しい機能（通常、実装中にいくつかのサブタスクに分割されます）が完了し、公開する準備ができると、セキュリティツールからのすべての出力が監査され、セキュリティの問題が検出されていないことを確認します。自動化されたツールによって特定された問題がない場合、セキュリティチームは最終的な手動レビューを行いました。次の図は、プロセス全体を示しています。

最終的なセキュリティレビューの結果は2つ考えられます。セキュリティの問題が見つからなかった場合は、新しい機能を公開する準備ができています。それ以外の場合、セキュリティチームは適切なバグを作成し、バグの進行状況を追跡し、バグが修正されると、プロセス全体が再度実行されます。

Kenticoクラウドセキュリティの詳細に興味がありますか？セキュリティポリシーを確認してください。