次の方法で共有

開発ライフサイクルを保護するためのレコメンデーション

  • [アーティクル]

この Power Platform Well-Architected Securityチェックリストの推奨事項に適用されます:

セ:02 強化され、大部分が自動化された監査可能なソフトウェア サプライ チェーンを使用して、安全な開発ライフサイクルを維持します。 脅威モデリングを使用して安全な設計を組み込み、セキュリティを損なう実装から保護します。

このガイドでは、開発サイクル全体でセキュリティのベスト プラクティスを適用することでコードと開発環境を保護するためのレコメンデーション について説明します。

ワークロードの中核となるのは、ビジネス ロジックを実装するコンポーネントです。 これらのコンポーネントには、キャンバス アプリやフローなどのローコード要素と、プラグインなどのコードファースト要素が混在する場合があります。 機密性、整合性、可用性を確保するために、ワークロードを構成するすべてのコンポーネントにセキュリティ上の欠陥がないことが必要です。

ID とネットワーク制御を使用してインフラストラクチャ プレーンを保護することは重要ですが、それだけでは十分ではありません。 不適切な実装を防ぐ Power Platform ワークロードとそのワークロード内の侵害されたアクティビティを特定して、全体的なセキュリティ体制を強化します。 セキュリティを開発ライフサイクルに統合するプロセスは、本質的には強化プロセスです。 リソースの強化と同様に、コード開発の強化もコンテキストに依存しません。 重点はアプリケーションの機能要件ではなく、セキュリティの強化にあります。

定義

任期 定義
セキュリティ開発ライフサイクル (SDL) マイクロソフトが提供する一連のプラクティスは、セキュリティ保証とコンプライアンス要件をサポートします。
ソフトウェア開発ライフサイクル (SDLC) ソフトウェア システムを開発するための多段階の体系的なプロセス。

主要な設計戦略

以下を確実にするために、セキュリティ対策を既存のソフトウェア開発ライフサイクル (SDLC) の複数の時点で統合する必要があります。

  • 設計の選択によってセキュリティ上のギャップが生じない。
  • ローコードおよびコードファーストのコンポーネントと構成で、悪用可能な実装や不適切なコーディング手法により脆弱性が発生しない。
  • ローコードおよびコードファーストのコンポーネントと展開プロセスが改ざんされない。
  • インシデントによって明らかになった脆弱性が軽減される。
  • コンプライアンス要件が侵害されたり、軽減されたりしない。
  • 監査ログはすべての環境に実装されている。

次のセクションでは、SDLC の一般的に実践されているフェーズのセキュリティ戦略について説明します。

要件フェーズ

要件フェーズの目標は、ワークロードまたはワークロードの新機能の機能要件と非機能要件を収集して分析することです。 このフェーズは、ワークロードの目的に合わせて調整された保護層の作成を容易にするために重要です。 データとワークロードの整合性の保護は、開発ライフサイクルのすべての段階を通じて中核となる要件である必要があります。

たとえば、ユーザーがアプリケーション内でデータを入力および変更するワークロードを考えてみましょう。 セキュリティ設計の選択には、ユーザー ID の認証と承認、データに対する許可されたアクションのみの許可など、ユーザーとデータのやり取りに対する保証が含まれる必要があります。 非機能要件には、可用性、使いやすさ、保守性が含まれます。 セキュリティの選択には、セグメンテーションの境界、ファイアウォールのイングレスとエグレス、その他の横断的なセキュリティ上の懸念事項を含める必要があります。

これらすべての決定は、ワークロードのセキュリティ体制の適切な定義につながるはずです。 合意された仕様でセキュリティ要件を文書化し、バックログに反映します。 このドキュメントには、セキュリティ投資と、投資がビジネス関係者によって承認されない場合に企業が引き受けるトレードオフとリスクを明示的に記載する必要があります。 たとえば、Power Platform 環境の IP ファイアウォールを使用して Dataverse アクセスを許可された IP ロケーションにのみ制限することで、組織のデータを保護します。 ビジネス関係者がマネージド環境のようなソリューションの使用に伴う追加コストを負担したくない場合は、コーヒー ショップなどの公共の場所から組織のリソースがアクセスされるリスクを受け入れる覚悟が必要です。 別の例として、アプリケーションがサードパーティの データ ソースに接続する必要があると想像してください。 Power Platform に、このための既製のコネクタがある可能性がありますが、セキュリティ チームによって承認された認証要件をサポートしていない可能性があります。 この場合、セキュリティ関係者は、未承認の認証方法を使用するリスクを喜んで受け入れる可能性があります。 あるいは、開発時間の増加とプロジェクトの遅延の可能性によるメリットを考慮しながら、カスタム コネクタの使用してみることもできます。

セキュリティ要件の収集はこのフェーズの重要な部分です。 この取り組みがなければ、設計と実装のフェーズは明示されていない選択に基づいて行われることになり、セキュリティ上のギャップや要件の変更につながり、開発時間が長くなる可能性があります。 セキュリティに対応するために後で実装を変更する必要がある場合がありますが、これには費用がかかる可能性があります。

設計フェーズ

このフェーズでは、セキュリティ要件が技術要件に変換されます。 実装中に曖昧さが生じないように、技術仕様ではすべての設計上の決定を文書化します。 以下が一般的なタスクです。

  • アーキテクチャのセキュリティ次元を定義する。 アーキテクチャをセキュリティ制御でオーバーレイします。 たとえば、ネットワーク分離境界で実用的な制御、ワークロードのコンポーネントに必要な ID と認証方法の種類、使用する暗号化方法の種類などです。

  • プラットフォームが提供するアフォーダンスを評価します。 あなたと Power Platform 間の責任分担を理解することが重要です。 Power Platform ネイティブ セキュリティ コントロールとの重複や複写を回避します。 セキュリティ適用範囲が広がり、アプリケーションのニーズに合わせて開発リソースを再割り当てできるようになります。

    たとえば、アプリやフロー内の未承認の使用パターンを事後的に識別して警告するカスタム ロジックを作成する代わりに、データ損失防止ポリシーを使用してコネクタの使用方法を分類します。

    信頼できるリファレンス実装、テンプレート、コード コンポーネント、スクリプト、ライブラリのみを選択してください。 設計では安全なバージョン管理も指定する必要があります。 アプリケーションの依存関係は信頼できる関係者から提供される必要があります。 サードパーティベンダーは、セキュリティ要件 を満たし、責任ある開示計画を共有 できる必要があります。 セキュリティ インシデントが発生した場合は、必要な措置を講じることができるように速やかに報告する必要があります。 また、特定のライブラリまたはリファレンス実装が組織によって禁止されている場合もあります。 たとえば、安全で脆弱性がない場合でも、組織でまだ承認されていない機能、ライセンス制限、またはリファレンス実装のサポート モデルを使用しているために、許可されない可能性があります。

    このガイダンスに確実に従うようにするには、承認済みおよび/または未承認のフレームワーク、ライブラリ、ベンダーのリストを管理し、作成者がこのリストをよく知っていることを確認してください。 可能であれば、リストをサポートするために開発パイプラインに保護層を配置します。 可能な限り、依存関係の脆弱性をスキャンするツールの使用を自動化します。

  • アプリケーションの秘密を安全に保存します。 アプリケーションが使用するアプリケーション シークレットと事前共有キーの使用を安全に実装します。 資格情報とアプリケーション シークレットは、ワークロード (アプリまたはフロー) のソース コードに保存しないでください。 Azure Key Vault などの外部リソースを使用して、潜在的な攻撃者がソース コードを利用できるようになった場合に、それ以上アクセスできないようにします。

  • 安全にデータへ接続します。 ロールベースや列レベルのセキュリティなど、データを保護するために Microsoft Dataverse が提供する強力なセキュリティ機能を利用してください。 他のデータ ソースの場合は、安全な認証方法を備えたコネクタを使用します。 ユーザー名とパスワードをプレーン テキストで保存するクエリは避けてください。 カスタム コネクタの作成には、HTTP を避けてください。

  • エンド ユーザーがどのようにワークロードとデータと対処するか定義します。 ユーザーがデータに直接アクセスできるかどうか、どのレベルのアクセスが必要か、どこからデータにアクセスするかを考慮します。 アプリケーションをエンド ユーザーとどのように共有するかを考えてください。 アプリとデータへのアクセスが必要なユーザーのみがアクセスできるようにします。 セキュリティ ブロッカーを回避するための回避策を促す複雑なセキュリティ モデルは避けてください。

  • ハード コーディングは避けてください。 URL とキーのハード コーディングは避けてください。 たとえば、Power Automate HTTP アクションでバックエンド サービスへの URL またはキーをハード コーディングすることは避けてください。 代わりに、カスタム コネクタを使用するか、URL には環境変数を使用し、API キーには Azure Key Vault を使用します。

  • テスト計画を定義します。 セキュリティ要件に対する明確なテスト ケースを定義します。 パイプラインでこれらのテストを自動化できるかどうかを評価します。 チームに手動テストのプロセスがある場合は、それらのテストのセキュリティ要件を含めます。

注意

このフェーズで脅威モデリングを実行します。 脅威モデリングにより、設計上の選択がセキュリティ要件と一致していることを確認し、軽減すべきギャップを明らかにすることができます。 ワークロードで機密性の高いデータを扱う場合は、脅威モデリングの実施を支援してくれるセキュリティ専門家に投資してください。

最初の脅威モデリング演習は、ソフトウェアのアーキテクチャと高レベルの設計が定義されている設計フェーズ中に実行する必要があります。 このフェーズでこれを行うと、潜在的なセキュリティ問題がシステムの構造に組み込まれる前に特定できるようになります。 ただし、この演習は 1 回限りのアクティビティではありません。 これは、ソフトウェアの進化を通じて継続するべき継続的なプロセスです。

詳細については、脅威分析に関するレコメンデーション を参照してください。

開発およびテスト フェーズ

このフェーズでの目標は セキュリティ上の欠陥と、コード、ビルド、展開パイプラインの改ざんを防ぐことです。

安全なコード実践について十分な訓練を受ける

開発チームには 安全なコーディング実践のトレーニングが必要です。 たとえば、開発者は、最小特権セキュリティ モデル、信頼できるドメインへの埋め込みを制限するモデル駆動型アプリのコンテンツ セキュリティ ポリシー、およびコネクタ/オンプレミス ゲートウェイ認証方法を実装する Microsoft Dataverse のセキュリティの概念に精通している必要があります。

開発者は、Power Platform ワークロードで作業を開始する前にこのトレーニングを完了する必要があります。

内部ピア コード レビューを実行して、継続的な学習を促進します。

コード分析ツールを使用する

ソリューション チェッカーは、Power Platform リソースに使用する必要があります。従来のコードのソース コードは、コード内の資格情報の存在など、潜在的なセキュリティ上の欠陥がないかチェックできます。 ソース コードと構成ファイルで資格情報と秘密が漏洩する可能性のあるインスタンスを特定します。 ここで、接続資格情報が運用環境でどのように処理されるかを確認するとよいでしょう。

ファジー テストを実施する

形式に誤りがある予期しないデータを使用して脆弱性をチェックし、エラー処理を検証します。これは、Power Pages などのソリューションで特に重要です。

適度なコードを書く

コード フットプリントを削減すると、セキュリティ上の欠陥が発生する可能性も減ります。 コードを複製するのではなく、すでに使用されていてセキュリティ検証済みのコードとライブラリを再利用します 。 オープンソース ソフトウェアの検出、バージョン、脆弱性、法的義務のチェック。 オープンソース Power Platform リソースが増えているため、見落としてはいけません。 可能であれば、土壇場での問題を回避するために、設計フェーズで話し合う必要があります。

開発者環境の保護

開発者のワークステーションは、漏洩を防ぐために強力なネットワークと ID 制御で保護する必要があります。 セキュリティ アップデートが定期的に適用されていることを確認してください。

ソースコードリポジトリも保護する必要があります 。 攻撃を回避するために、コード リポジトリへのアクセスを必要に応じて許可し、脆弱性の露出を可能な限り減らします。 セキュリティ上の脆弱性がないかコードをレビューするための徹底したプロセスを用意します。 この目的でセキュリティ グループを使用し、業務上の正当な理由に基づいた承認プロセスを実装します。

コード展開を保護する

コードを保護するだけでは十分ではありません。 悪用可能なパイプラインで実行される場合、すべてのセキュリティ対策は無駄で不完全になります。 悪意のあるユーザーがパイプライン内で悪意のあるコードを実行するのを防ぐため、ビルド環境とリリース環境も保護する必要があります 。

アプリケーションに統合されているすべてのコンポーネントの最新のインベントリを維持する

アプリケーションに統合される新しいコンポーネントごとに、攻撃面が増加します。 新しいコンポーネントが追加または更新されたときに適切な説明責任とアラートを保証するには、これらのコンポーネントのインベントリを作成する必要があります。 定期的に、マニフェストがビルド プロセスの内容と一致していることを確認します。 そうすることで、バック ドアやその他のマルウェアを含む新しいコンポーネントが予期せず追加されないようにすることができます。

展開には、Power Platform のパイプライン を使用することをお勧めします。 GitHub Actions を使用してパイプラインを拡張します。 GitHub ワークフローを使用する場合は、マイクロソフトが作成したタスクを優先してください。 また、タスクはパイプラインのセキュリティ コンテキストで実行されるため、検証する必要があります。

展開のためのサービス プリンシパルの使用を検討します。

運用フェーズ

運用フェーズは、セキュリティのギャップを修正する最後の責任ある機会です。 運用中にリリースされるゴールデン イメージを記録します。

バージョン管理された成果物を保持する

展開されたすべての資産とそのバージョンのカタログを保持します。 この情報は、インシデントの優先順位付け時、問題を軽減するとき、およびシステムを動作状態に戻すときに役立ちます。 バージョン管理された資産は、公開されたCommon Vulnerabilities and Exposures (CVE) 通知と比較することもできます。 これらの比較を実行するには、自動化を使用する必要があります。

緊急修正

自動化されたパイプラインの設計には、通常の展開と緊急展開の両方をサポートする柔軟性が必要です。 この柔軟性は、迅速かつ責任あるセキュリティ修正をサポートするために重要です。

リリースは通常、複数の承認ゲートに関連付けられます。 セキュリティ修正を迅速化するための緊急プロセスの作成を検討してください。 このプロセスには、チーム間のコミュニケーションが含まれる場合があります。 パイプラインでは、通常の展開ライフサイクル外で発生するセキュリティ修正、重大なバグ、コード更新に対処する、迅速なロールフォワードおよびロールバック展開を可能にする必要があります。

注意

常に利便性よりもセキュリティ修正を優先します。 セキュリティ修正によって回帰やバグが発生してはなりません。 緊急パイプラインを通じて修正を加速したい場合は、どの自動テストをバイパスできるかを慎重に検討してください。 各テストの値を実行時間に対して評価します。 たとえば、ユニット テストは通常すぐに完了します。 統合テストまたはエンドツーエンド テストの実行には、長時間かかる場合があります。

異なる環境を分離する

これらの環境には、運用環境のような厳格なセキュリティ制御が適用されていない可能性があるため、運用データは下位の環境**では使用しないでください。 非運用アプリケーションから運用データベースへの接続や、非運用コンポーネントから運用ネットワークへの接続は避けてください。

プログレッシブ曝露を使用する

プログレッシブ曝露を使用して、選択した基準に基づいて 一部のユーザーに機能をリリース します。 問題が発生した場合でも、ユーザーへの影響は最小限に抑えられます。 このアプローチは、セキュリティ、外部からのアクセスを減らすので、一般的なリスク軽減戦略です。 機能が成熟し、セキュリティ保証に自信が持てるようになったら、段階的により幅広いユーザーにリリースできます。

メンテナンス フェーズ

このフェーズの目標は、セキュリティ体制が時間の経過とともに低下しないようにすることです。 SDLC は継続的なアジャイル プロセスです。 要件は時間の経過とともに変化するため、前のフェーズで説明した概念がこのフェーズにも適用されます。

継続的な改善。 コード レビュー、フィードバック、学んだ教訓、進化する脅威、Power Platform が提供する新機能を考慮して、ソフトウェア開発プロセスのセキュリティを継続的に評価し改善します。

古くなった、または使用されなくなったレガシー資産 を廃止します。 そうすることで、アプリケーションのセキュリティ、外部からのアクセスが減少します。

メンテナンスにはインシデントの修正も含まれます。 運用中に問題が見つかった場合は、再発しないようにすぐにプロセスに組み込む必要があります。

脅威の状況に対応するために、安全なコーディングの実践を継続的に改善してください。

Microsoft Power Platform の SDL

Power Platform は、安全設計の文化と方法論に基づいて構築されています。 Microsoft の業界をリードする セキュリティ開発ライフサイクル (SDL) と 脅威モデリング のプラクティスにより、文化と方法論の両方が常に強化されています。

脅威モデリングのレビュー プロセスにより、設計段階で脅威を特定し、軽減し、検証して、軽減されたことを確認します。

脅威モデリングでは、継続的かつ定期的なレビューを通じて既に実施されているサービスへのすべての変更も考慮されます。 STRIDE モデル に依存することで、安全でない設計に関する最も一般的な問題に対処することができます。

Microsoft の SDL は、OWASP Software Assurance Maturity Model (SAMM) に相当します。 どちらも、安全な設計が Web アプリケーションのセキュリティに不可欠であるという前提に基づいて構築されています。 詳細については、OWASP リスクの上位 10:Power Platform での軽減策を参照してください。

Power Platform の促進

Microsoft セキュリティ開発ライフサイクル (SDL) では、開発ライフサイクルに適用できる安全なプラクティスを推奨しています。 詳細については、Microsoft セキュリティ開発ライフサイクル を参照してください。

Defender for DevOps と SAST (静的アプリケーション セキュリティ テスト) ツールは、GitHub Advanced Security および Azure DevOps の一部として含まれています。 これらのツールは、組織のセキュリティ スコアを追跡するのに役立ちます。

ソリューション チェッカー機能を使用すると、一連のベスト プラクティス ルールに対してソリューションで機能豊富なスタティック分析チェックを実行し、これらの問題となるパターンを識別できます。 ソリューション チェッカーを使用してソリューションを検証するを参照してください。

セキュリティ チェックリスト

完全なレコメンデーションのセットを参照してください。

セキュリティチェックリスト