다음을 통해 공유

개발 수명 주기 보호를 위한 권장 사항

  • 아티클

이 Power Platform Well-Architected Security 체크리스트 권장 사항에 적용됩니다.

SE:02 강화되고 대부분 자동화되었으며 감사 가능한 소프트웨어 공급망을 사용하여 안전한 개발 수명주기를 유지하세요. 보안을 위협하는 구현으로부터 보호하기 위해 위협 모델링을 사용하여 보안 설계를 통합합니다.

이 가이드에서는 개발 주기 전반에 걸쳐 보안 모범 사례를 적용하여 코드 및 개발 환경을 보호하기 위한 권장 사항을 설명합니다.

워크로드의 핵심에는 비즈니스 로직을 구현하는 구성 요소가 있습니다. 이러한 구성 요소는 캔버스 앱 및 흐름과 같은 로우코드 요소와 플러그인과 같은 코드 우선 요소가 혼합되어 있을 수 있습니다. 기밀성, 무결성 및 가용성을 보장하려면 워크로드를 구성하는 모든 구성 요소에 보안 결함이 없어야 합니다.

ID 및 네트워킹 제어를 통해 인프라 측면을 보호하는 것이 중요하지만 그것만으로는 충분하지 않습니다. Power Platform 워크로드의 잘못된 구현과 해당 워크로드에서 손상된 활동을 방지하여 전반적인 보안 상태를 강화하세요. 개발 수명 주기에 보안을 통합하는 프로세스는 본질적으로 강화 프로세스입니다. 리소스 강화와 마찬가지로 코드 개발 강화도 상황에 구애 받지 않습니다. 애플리케이션의 기능적 요구 사항이 아니라 보안 강화에 중점을 둡니다.

정의

용어 정의
보안 개발 수명 주기(SDL) 보안 보증 및 규정 준수 요구 사항을 지원하는 Microsoft 에서 제공하는 일련의 관행입니다.
소프트웨어 개발 수명 주기(SDLC) 소프트웨어 시스템 개발을 위한 다단계의 체계적인 프로세스입니다.

주요 디자인 전략

보안 조치는 다음을 보장하기 위해 기존 소프트웨어 개발 수명 주기(SDLC)의 여러 지점에서 통합되어야 합니다.

  • 디자인 선택으로 인한 보안 격차는 발생하지 않습니다.
  • 로우코드 및 코드 우선 구성 요소와 구성은 악용 가능한 구현 및 부적절한 코딩 관행으로 인해 취약점을 생성하지 않습니다.
  • 로우코드 및 코드 우선 구성 요소와 배포 프로세스는 변조되지 않습니다.
  • 인시던트를 통해 드러난 취약점이 완화됩니다.
  • 규정 준수 요구 사항이 침해되거나 축소되지 않습니다.
  • 감사 로깅은 모든 환경에서 구현됩니다.

다음 섹션에서는 일반적으로 실행되는 SDLC 단계에 대한 보안 전략을 제공합니다.

요구 사항 단계

요구 사항 단계의 목표는 워크로드 또는 워크로드의 새로운 기능에 대한 기능적 요구 사항과 비기능적 요구 사항을 수집하고 분석하는 것입니다. 이 단계는 워크로드 목표에 맞게 조정된 가드레일을 쉽게 생성할 수 있기 때문에 중요합니다. 워크로드의 데이터와 무결성을 보호하는 것은 개발 수명 주기의 모든 단계에서 핵심 요구 사항이 되어야 합니다.

예를 들어, 사용자가 애플리케이션 내에서 데이터를 입력하고 수정하는 워크로드를 생각해 보세요. 보안 설계 선택에는 사용자 ID 인증 및 권한 부여, 데이터에 대해 허용된 작업만 허용 등 사용자와 데이터의 상호 작용에 대한 보장이 포함되어야 합니다. 비직무적 요구 사항에는 가용성, 유용성 및 유지 관리 가능성이 포함됩니다. 보안 선택 사항에는 세분화 경계, 방화벽 수신 및 송신, 기타 교차 보안 문제가 포함되어야 합니다.

이러한 모든 결정은 워크로드의 보안 상태에 대한 올바른 정의로 ​​이어져야 합니다. 합의된 사양에 보안 요구 사항을 문서화하고 이를 백로그에 반영합니다. 문서에는 보안 투자와 비즈니스 이해관계자가 투자를 승인하지 않을 경우 비즈니스가 감수할 의향이 있는 장단점 및 위험이 명시적으로 기술되어 있어야 합니다. 예를 들어, 허용된 IP 위치로만 Dataverse 액세스를 제한하여 조직 데이터를 보호하기 위해 Power Platform 환경에서 IP 방화벽을 사용해야 할 필요성을 문서화할 수 있습니다. 비즈니스 이해관계자가 관리 환경과 같은 솔루션을 사용하는 데 드는 추가 비용을 감당할 의사가 없다면 커피숍과 같은 공공 장소에서 조직 리소스에 액세스하는 위험을 감수할 준비가 되어 있어야 합니다. 또 다른 예로, 애플리케이션이 타사 데이터 원본에 연결되어야 한다고 가정해 보겠습니다. Power Platform에는 이를 위한 기성 커넥터가 있을 수 있지만 보안팀에서 승인한 인증 요구 사항을 지원하지 않을 수 있습니다. 이 경우 보안 이해 관계자는 승인되지 않은 인증 방법을 사용하는 위험을 기꺼이 감수할 수 있습니다. 또는 개발 시간 증가와 잠재적인 프로젝트 지연의 이점을 비교하면서 사용자 지정 커넥터를 사용해 볼 수도 있습니다.

보안 요구 사항 수집은 이 단계의 중요한 부분입니다. 이러한 노력이 없으면 설계 및 구현 단계는 명시되지 않은 선택에 기초하게 되며, 이로 인해 보안 격차가 발생하거나 요구 사항이 변경되어 개발 시간이 늘어날 수 있습니다. 보안을 수용하기 위해 나중에 구현을 변경해야 할 수도 있으며, 이는 비용이 많이 들 수 있습니다.

설계 단계

이 단계에서는 보안 요구 사항이 기술 요구 사항으로 변환됩니다. 구현 중 모호함을 방지하기 위해 기술 사양에 모든 설계 결정을 문서화하세요. 다음은 몇 가지 일반적인 작업입니다.

  • 아키텍처의 보안 차원을 정의합니다. 보안 제어로 아키텍처를 오버레이합니다. 예를 들어 네트워크 격리 경계에 대한 실용적인 제어, 워크로드 구성 요소에 필요한 ID 유형 및 인증 방법, 사용할 암호화 방법 유형 등이 있습니다.

  • 플랫폼에서 제공하는 어포던스를 평가합니다. 사용자와 Power Platform 간의 책임 부문을 이해하는 것이 중요합니다. Power Platform 기본 보안 컨트롤과 겹치거나 중복되지 않도록 합니다. 더 나은 보안 범위를 확보하고 개발 리소스를 애플리케이션 요구 사항에 맞게 재할당할 수 있습니다.

    예를 들어 앱과 흐름에서 승인되지 않은 사용 패턴을 반응적으로 식별하고 경고하는 사용자 지정 논리를 만드는 대신 데이터 손실 방지 정책을 사용하여 커넥터를 사용할 수 있는 방법을 분류합니다.

    신뢰할 수 있는 참조 구현, 템플릿, 코드 구성 요소, 스크립트 및 라이브러리만 선택하세요. 설계에서는 보안 버전 제어도 지정해야 합니다. 애플리케이션 종속성은 신뢰할 수 있는 당사자로부터 제공되어야 합니다. 타사 공급업체는 보안 요구 사항을 충족할 수 있어야 하며 책임 있는 공개 계획을 공유해야 합니다. 모든 보안 인시던트는 즉시 보고되어 필요한 조치를 취할 수 있도록 해야 합니다. 또한 특정 라이브러리 또는 참조 구현은 조직에서 금지할 수 있습니다. 예를 들어, 안전하고 취약점이 없더라도 조직에서 아직 승인하지 않은 기능, 라이선스 제한 또는 참조 구현의 지원 모델을 사용하기 때문에 여전히 허용되지 않을 수 있습니다.

    이 지침을 따르려면 승인 및/또는 승인되지 않은 프레임워크, 라이브러리 및 공급업체 목록을 유지하고 제작자가 이 목록을 숙지하고 있는지 확인하세요. 가능하다면 개발 파이프라인에 가드레일을 배치하여 목록을 지원하세요. 가능한 한 취약점에 대한 종속성을 검사하는 도구 사용을 자동화하세요.

  • 애플리케이션 비밀을 안전하게 저장하세요. 애플리케이션에서 사용하는 애플리케이션 비밀 및 사전 공유 키의 사용을 안전하게 구현합니다. 자격 증명과 애플리케이션 비밀은 워크로드(앱 또는 흐름)의 소스 코드에 저장하지 마십시오. 잠재적 공격자가 소스 코드를 사용할 수 있게 되면 더 이상 액세스할 수 없도록 Azure Key Vault와 같은 외부 리소스를 사용하세요.

  • 데이터에 안전하게 연결하세요. 역할 기반 및 열 수준 보안과 같은 Microsoft Dataverse의 강력한 보안 기능을 사용하여 데이터를 보호하세요. 다른 데이터 원본의 경우 보안 인증 방법이 있는 커넥터를 사용하세요. 사용자 이름과 암호를 일반 텍스트로 저장하는 쿼리는 피하세요. 사용자 지정 커넥터를 만들 때 HTTP를 사용하지 마세요.

  • 최종 사용자가 워크로드 및 데이터와 상호 작용하는 방법을 정의합니다. 사용자가 데이터에 직접 액세스할 수 있는지 여부, 필요한 액세스 수준, 데이터에 액세스할 위치를 고려하세요. 애플리케이션이 최종 사용자와 어떻게 공유될지 생각해 보세요. 앱과 데이터에 액세스해야 하는 사람만 액세스할 수 있도록 하세요. 보안 차단 요인을 피하기 위해 해결 방법을 권장하는 복잡한 보안 모델을 피하세요.

  • 하드 코딩을 피하세요. URL과 키를 하드 코딩하지 마세요. 예를 들어 Power Automate HTTP 작업에서 백엔드 서비스에 대한 URL 또는 키를 하드 코딩하지 마세요. 대신 사용자 지정 커넥터를 사용하거나 URL에 환경 변수를 사용하고 API 키에 Azure Key Vault를 사용하세요.

  • 테스트 계획을 정의합니다. 보안 요구 사항에 대한 명확한 테스트 사례를 정의합니다. 파이프라인에서 이러한 테스트를 자동화할 수 있는지 평가하세요. 팀에 수동 테스트를 위한 프로세스가 있는 경우 해당 테스트에 대한 보안 요구 사항을 포함하세요.

참고

이 단계에서 위협 모델링을 수행합니다. 위협 모델링을 통해 설계 선택이 보안 요구사항에 부합하는지 확인하고 완화해야 할 격차를 노출할 수 있습니다. 워크로드가 매우 중요한 데이터를 처리하는 경우 위협 모델링 수행에 도움을 줄 수 있는 보안 전문가에게 투자하세요.

초기 위협 모델링 연습은 소프트웨어의 아키텍처와 상위 수준 설계가 정의되는 설계 단계에서 이루어져야 합니다. 해당 단계에서 이를 수행하면 잠재적인 보안 문제가 시스템 구조에 통합되기 전에 이를 식별하는 데 도움이 됩니다. 그러나 이 연습은 일회성 활동이 아닙니다. 이는 소프트웨어가 발전하는 동안 계속되어야 하는 지속적인 프로세스입니다.

자세한 내용은 위협 분석에 대한 권장 사항을 참조하세요.

개발 및 테스트 단계

이 단계의 목표는 보안 결함을 방지하고 코드, 빌드 및 배포 파이프라인의 변조를 방지하는 것입니다.

보안 코드 관행에 대해 충분한 교육 받기

개발팀은 보안 코딩 관행에 대한 교육을 받아야 합니다. 예를 들어 개발자는 최소 권한 보안 모델, 신뢰할 수 있는 도메인으로 포함을 제한하기 위한 모델 기반 앱에 대한 콘텐츠 보안 정책 및 커넥터/온-프레미스 게이트웨이 인증 방법을 구현하기 위해 Microsoft Dataverse의 보안 개념에 익숙해야 합니다.

개발자는 Power Platform 워크로드에 대한 작업을 시작하기 전에 이 교육을 완료해야 합니다.

지속적인 학습을 촉진하기 위해 내부 동료 코드 검토를 수행합니다.

코드 분석 도구 사용

솔루션 검사기는 Power Platform 리소스에 사용해야 하며, 코드에 자격 증명이 있는지 포함하여 기존 코드의 소스 코드에 잠재적인 보안 결함이 있는지 확인할 수 있습니다. 소스 코드 및 구성 파일에서 자격 증명 및 비밀 노출 가능성이 있는 인스턴스를 식별합니다. 이때가 프로덕션에서 연결 자격 증명이 어떻게 처리되는지 검토할 좋은 시점입니다.

퍼즈 테스트 수행

잘못된 형식의 예기치 않은 데이터를 사용하여 취약성을 확인하고 오류 처리의 유효성을 검사하는 것은 특히 Power Pages가 포함된 솔루션에서 중요합니다.

필요한 만큼만 코드 작성

코드 공간을 줄이면 보안 결함이 발생할 가능성도 줄어듭니다. 코드를 복제하는 대신 이미 사용 중이고 보안 검증을 거친 코드와 라이브러리를 재사용하세요. 오픈 소스 소프트웨어 감지 및 버전, 취약성, 법적 의무 확인. 오픈 소스 Power Platform 리소스의 양이 점점 늘어나고 있으므로 이를 간과해서는 안 됩니다. 가능하다면 최종 단계의 문제를 방지하기 위해 설계 단계에서 이에 대해 논의해야 합니다.

개발자 환경 보호

개발자 워크스테이션은 노출을 방지하기 위해 강력한 네트워크 및 ID 제어로 보호되어야 합니다. 보안 업데이트가 적절히 적용되었는지 확인하세요.

소스 코드 저장소도 안전하게 보호되어야 합니다. 알아야 할 필요에 따라 코드 리포지토리에 대한 액세스 권한을 부여하고 공격을 피하기 위해 취약점 노출을 최대한 줄입니다. 보안 취약점을 찾기 위해 코드를 철저히 검토하는 프로세스를 갖추세요. 해당 목적으로 보안 그룹을 사용하고 비즈니스 정당성을 기반으로 승인 프로세스를 구현하십시오.

보안 코드 배포

코드를 보호하는 것만으로는 충분하지 않습니다. 코드가 악용 가능한 파이프라인에서 실행되면 모든 보안 노력은 소용이 없고 불완전합니다. 빌드 및 릴리스 환경도 보호해야 합니다. 이유는 악의적인 행위자가 파이프라인에서 악성 코드를 실행하지 못하도록 방지하기 위해서입니다.

애플리케이션에 통합된 모든 구성 요소의 최신 인벤토리 유지 관리

애플리케이션에 통합되는 모든 새로운 구성 요소는 공격 표면을 증가시킵니다. 새로운 구성 요소가 추가되거나 업데이트될 때 적절한 책임과 경고를 보장하려면 이러한 구성 요소에 대한 인벤토리가 있어야 합니다. 정기적으로 매니페스트가 빌드 프로세스의 내용과 일치하는지 확인하세요. 이렇게 하면 백도어나 기타 멀웨어가 포함된 새 구성 요소가 예기치 않게 추가되지 않도록 할 수 있습니다.

배포에는 Power Platform용 파이프라인을 사용하는 것이 좋습니다. GitHub Actions를 사용하여 파이프라인을 확장하세요. GitHub 워크플로를 사용하는 경우 Microsoft-작성 작업을 선호합니다. 또한 작업은 파이프라인의 보안 컨텍스트에서 실행되므로 유효성을 검사하세요.

배포를 위한 서비스 주체 사용을 살펴보세요.

프로덕션 단계

프로덕션 단계에서는 보안 격차를 해결할 수 있는 마지막 책임 있는 기회를 제공합니다. 프로덕션에서 공개되는 골든 이미지를 기록하세요.

버전이 지정된 아티팩트 유지

배포된 모든 자산과 해당 버전의 카탈로그를 유지합니다. 이 정보는 인시던트 분류 중에, 문제를 완화할 때, 시스템을 다시 작동 상태로 되돌릴 때 유용합니다. 버전이 지정된 자산을 게시된 CVE(Common Vulnerability and Exposures) 공지와 비교할 수도 있습니다. 이러한 비교를 수행하려면 자동화를 사용해야 합니다.

긴급 수정

자동화된 파이프라인 설계에는 일반 배포와 긴급 배포를 모두 지원할 수 있는 유연성이 있어야 합니다. 이러한 유연성은 신속하고 책임감 있는 보안 수정을 지원하는 데 중요합니다.

릴리스는 일반적으로 여러 승인 게이트와 연결됩니다. 보안 수정을 가속화하기 위해 긴급 프로세스를 만드는 것이 좋습니다. 프로세스에는 팀 간의 의사소통이 포함될 수 있습니다. 파이프라인은 정규 배포 수명 주기 외에 발생하는 보안 수정, 중요한 버그 및 코드 업데이트를 해결하는 빠른 롤포워드 및 롤백 배포를 허용해야 합니다.

참고

항상 편의성보다 보안 수정을 우선시하세요. 보안 수정으로 인해 회귀나 버그가 발생해서는 안 됩니다. 긴급 파이프라인을 통해 수정을 가속화하려면 어떤 자동화 테스트를 우회할 수 있는지 신중하게 고려하세요. 실행 시간과 비교하여 각 테스트의 가치를 평가하세요. 예를 들어 단위 테스트는 일반적으로 빠르게 완료됩니다. 통합 또는 엔드투엔드 테스트는 오랫동안 실행될 수 있습니다.

서로 다른 환경을 별도로 유지

프로덕션 데이터는 하위 환경에서** 사용하면 안 됩니다. 이러한 환경에는 프로덕션에 적용되는 엄격한 보안 제어가 없을 수 있기 때문입니다. 비프로덕션 애플리케이션에서 프로덕션 데이터베이스에 연결하지 말고, 비프로덕션 구성 요소를 프로덕션 네트워크에 연결하지 마세요.

점진적 노출 사용

점진적 노출을 사용하여 선택한 기준에 따라 하위 사용자 집합에 기능을 릴리스합니다. 문제가 있는 경우 해당 사용자에게 미치는 영향은 최소화됩니다. 이 접근 방식은 공격 표면적을 줄이기 때문에 일반적인 위험 완화 전략입니다. 기능이 성숙해지고 보안 보증에 대한 확신이 높아지면 점차적으로 더 많은 사용자에게 릴리스할 수 있습니다.

유지 관리 단계

이 단계의 목표는 시간이 지나도 보안 상태가 약화되지 않도록 하는 것입니다. SDLC는 지속되는 민첩한 프로세스입니다. 시간이 지남에 따라 요구 사항이 변경되므로 이전 단계에서 다룬 개념이 이 단계에 적용됩니다.

지속적인 개선. 코드 검토, 피드백, 학습한 내용, 진화하는 위협, Power Platform에서 제공하는 새로운 기능을 고려하여 소프트웨어 개발 프로세스의 보안을 지속적으로 평가하고 개선합니다.

오래되었거나 더 이상 사용되지 않는 레거시 자산을 폐기합니다. 이렇게 하면 애플리케이션의 표면적이 줄어듭니다.

유지 관리에는 인시던트 수정도 포함됩니다. 프로덕션에서 문제가 발견되면 문제가 재발되지 않도록 즉시 프로세스에 다시 통합해야 합니다.

위협 환경에 발맞춰 보안 코딩 방식을 지속적으로 개선하세요.

Microsoft Power Platform의 SDL

Power Platform은 보안 설계의 문화와 방법론을 기반으로 빌드됩니다. 문화와 방법론은 모두 업계를 선도하는 Microsoft보안 개발 수명 주기 (SDL) 및 위협 모델링 실무를 통해 끊임없이 강화됩니다.

위협 모델링 검토 프로세스는 설계 단계에서 위협을 식별하고, 완화하고, 위협이 완화되었는지 확인하도록 확인합니다.

위협 모델링은 또한 지속적인 정기 검토를 통해 이미 실행 중인 서비스에 대한 모든 변경 사항을 설명합니다. STRIDE 모델에 의존하여 안전하지 않은 설계와 관련된 가장 일반적인 문제를 해결하는 데 도움이 됩니다.

Microsoft'의 SDL은 OWASP 소프트웨어 보증 성숙도 모델 (SAMM)과 동일합니다. 둘 다 보안 설계가 웹 애플리케이션 보안에 필수적이라는 전제에 구축되었습니다. 자세한 내용은 OWASP 상위 10대 위험: Power Platform의 완화 방법을 참조하세요.

Power Platform 간편 사용

Microsoft 보안 개발 수명 주기(SDL)는 개발 수명 주기에 적용할 수 있는 보안 관행을 권장합니다. 자세한 내용은 Microsoft 보안 개발 수명 주기를 참조하세요.

Defender for DevOps 및 SAST(정적 애플리케이션 보안 테스트) 도구는 GitHub Advanced Security 및 Azure DevOps의 일부로 포함됩니다. 이러한 도구는 조직의 보안 점수를 추적하는 데 도움이 될 수 있습니다.

솔루션 검사 기능을 사용하면 모범 사례 규칙 세트에 따라 솔루션에 대한 풍부한 정적 분석 검사를 수행하고 이러한 문제 패턴을 신속하게 식별할 수 있습니다. See 솔루션 검사기를 사용하여 솔루션 유효성 검사를 참조하세요.

보안 체크리스트

전체 권장 사항 세트를 참조하세요.

보안 체크리스트