Power Apps와 함께 안전하게 Microsoft SQL Server 사용
Power Apps를 사용하여 SQL 서버에 연결하고 인증하는 다양한 방법이 있습니다. 이 문서에서는 앱의 요구 사항과 일치하는 보안 접근 방식을 사용하여 SQL Server에 연결하는 방법을 선택하는 데 도움이 될 수 있는 개념을 간략하게 설명합니다.
중요
보안 암시적 연결 기능은 2024년 1월에 출시되었습니다. Microsoft는 현재 암시적 연결을 사용하는 모든 앱이 안전한 암시적 연결로 변환하고 최종 사용자와 공유된 연결을 취소할 것을 강력히 권장합니다.
명시적, 암시적 및 보안 암시적 연결의 차이점
SQL Server에 연결하는 Power Apps를 사용하여 앱을 만들 때마다 SQL Server에 대한 연결이 생성됩니다. 이런 앱이 게시되고 다른 사용자와 공유되면 앱과 연결이 모두 해당 사용자에게 배포됩니다. 즉, 앱과 연결 — 둘 모두 앱이 공유된 사용자에게 표시됩니다.
이런 연결에 사용되는 인증 방법은 명시적 또는 암시적일 수 있습니다. 그런 연결이 명시적 또는 암시적으로 공유된다고 말할 수도 있습니다.
- 명시적으로 공유된 연결은 애플리케이션의 최종 사용자가 자신의 명시적 자격 증명을 사용하여 SQL Server에 인증해야 함을 의미합니다. 일반적으로 이런 인증은 Microsoft Entra 또는 Windows 인증 핸드셰이크의 일부로 배후에서 이루어집니다. 사용자는 인증이 수행될 때조차 알아차리지 못합니다.
- 암시적 공유 연결은 앱 제작자가 앱을 만드는 동안 데이터 소스에 연결하고 인증하는 데 사용한 계정의 자격 증명을 사용자가 암시적으로 사용함을 의미합니다. 최종 사용자의 자격 증명은 인증에 사용되지 않습니다. 최종 사용자는 앱을 실행할 때마다 작성자가 앱을 만들 때 사용한 자격 증명을 사용합니다.
- 암시적 공유 보안 연결은 앱의 최종 사용자가 앱을 만드는 동안 앱 제작자가 데이터 원본에 연결하고 인증하는 데 사용한 계정의 자격 증명을 암시적으로 사용하는 시나리오를 나타냅니다. 즉, 최종 사용자의 자격 증명은 인증에 사용되지 않습니다. 대신 사용자가 앱을 실행할 때 앱 작성자가 앱을 만드는 데 사용한 자격 증명을 사용합니다. 최종 사용자에게는 연결에 대한 직접적인 액세스 권한이 제공되지 않으며 앱에서는 제한된 작업 및 테이블 세트에만 액세스할 수 있다는 점에 유의하는 것이 중요합니다.
Power Apps에 대해 SQL Server에서 다음 네 가지 연결 인증 유형을 사용할 수 있습니다.
| 인증 유형 | Power Apps 연결 방법 |
|---|---|
| Microsoft Entra Integrated | 명시적 |
| SQL Server 인증 | 암시적 / 보안 암시적 |
| Windows 인증 | 암시적 / 보안 암시적 |
| Windows 인증(비공유) | 명시적 |
암시적 연결 공유 위험
모든 새로운 애플리케이션은 자동으로 새로운 보안 암시적 연결을 사용합니다. 그러나 이전 '암시적 연결'을 사용하는 앱의 경우 앱과 해당 연결이 모두 최종 사용자에게 배포됩니다. 이는 최종 사용자가 이런 연결을 기반으로 새 애플리케이션을 작성할 수 있음을 의미합니다.
작성자가 보안 암시적 연결을 사용하는 경우 연결이 공유되지 않고 최종 사용자가 연결 개체를 수신하지 않음을 의미합니다. 이렇게 하면 최종 사용자 작성자가 연결을 재사용하여 새 앱을 만드는 위험이 제거됩니다. 대신, 앱은 앱을 인식하고 해당 특정 앱과만 통신하는 프록시 연결을 사용하여 작동합니다. 프록시 연결을 사용하면 제한된 작업(만들기, 읽기, 업데이트, 삭제)과 앱 게시 시 정의된 앱의 특정 테이블에 대한 액세스가 허용됩니다. 따라서 승인된 작업과 액세스만 최종 사용자에게 부여됩니다.
이전 스타일의 단순 암시적 연결은 실제로 연결 개체를 최종 사용자에게 배포합니다. 예를 들어 사용자에게 표시하지 않으려는 데이터를 필터링하는 앱을 만드는 경우입니다. 하지만 필터링된 데이터가 데이터베이스에 있습니다. 그러나 최종 사용자가 특정 데이터를 볼 수 없도록 구성한 필터에 의존하고 있습니다.
다시 말하지만, 이전 스타일의 단순 암시적 연결을 사용하면 해당 앱을 배포한 후 최종 사용자는 자신이 만드는 모든 새 앱에서 앱과 함께 배포된 연결을 사용할 수 있습니다. 새 앱에서 사용자는 애플리케이션에서 필터링한 데이터를 볼 수 있습니다. 새로운 보안 암시적 연결을 사용하는 것이 중요합니다.
중요
이전 암시적 공유 연결이 최종 사용자에게 배포되면 공유한 앱에 설정한 제한 사항(예: 필터 또는 읽기 전용 액세스)이 최종 사용자가 만드는 새 앱에 더 이상 유효하지 않습니다. 최종 사용자는 암시적으로 공유된 연결의 일부로 인증이 허용하는 모든 권한을 갖습니다. 따라서 보안 암시적 연결을 사용하도록 앱을 변환하는 경우 앱과 공유한 연결도 취소해야 합니다. 관리자는 COE 툴킷과 암시적으로 공유된 연결이 있는 앱에 대한 보고서를 얻을 수 있습니다.
클라이언트 및 서버 보안
필터링이나 기타 클라이언트 측 작업을 통한 데이터 보안에 의존할 수는 없습니다. 데이터의 보안 필터링이 필요한 애플리케이션은 사용자 식별과 필터링이 모두 서버에서 발생하도록 해야 합니다.
사용자 ID 및 보안과 관련하여 앱 내에 설계된 필터에 의존하는 대신 Microsoft Entra ID와 같은 서비스를 사용하십시오. 이 구성은 서버 측 필터가 예상대로 작동하도록 합니다.
다음 그림은 클라이언트 측 보안 모델과 서버 측 보안 모델 간에 앱 내의 보안 패턴이 어떻게 다른지 설명합니다.
클라이언트 보안 앱 패턴에서 [1] 사용자는 클라이언트 측의 애플리케이션에만 인증합니다. 그런 다음 [2] 애플리케이션은 서비스 정보를 요청하고 [3] 서비스는 데이터 요청만을 기반으로 정보를 반환합니다.
서버 측 보안 패턴에서 [1] 사용자는 먼저 서비스에 인증하여 사용자가 서비스에 알려지도록 합니다. 그런 다음 [2] 애플리케이션에서 호출이 발생하면 [3] 서비스는 현재 사용자의 알려진 ID를 사용하여 데이터를 적절하게 필터링하고 [4]는 데이터를 반환합니다.
위에서 설명한 암시적 부서별 공유 시나리오는 이 두 패턴의 조합입니다. 사용자는 Microsoft Entra 자격 증명을 사용하여 Power Apps 서비스에 로그인해야 합니다. 이 동작은 서버 보안 앱 패턴입니다. 사용자는 서비스에서 Microsoft Entra ID를 사용하여 알려져 있습니다. 따라서 앱은 Power Apps가 응용 프로그램을 공식적으로 공유한 사용자 집합으로 제한됩니다.
그러나 SQL Server에 대한 암시적 공유 연결은 클라이언트 보안 앱 패턴입니다. SQL Server는 특정 사용자 이름과 암호가 사용되었다는 사실만 알고 있습니다. 예를 들어, 모든 클라이언트 측 필터링은 동일한 사용자 이름과 암호를 사용하는 새 애플리케이션으로 우회할 수 있습니다.
서버 측에서 데이터를 안전하게 필터링하려면 행에 대한 행 수준 보안 및 특정 사용자에 대한 특정 개체(예: 열)에 대한 권한 거부와 같은 SQL Server의 기본 제공 보안 기능을 사용합니다. 이 접근 방식은 Microsoft Entra 사용자 ID를 사용하여 서버의 데이터를 필터링합니다.
일부 기존 기업 서비스는 Microsoft Dataverse와 거의 동일한 방식으로 비즈니스 데이터 계층에서 사용자 ID를 캡처하는 접근 방식을 사용했습니다. 이 경우 비즈니스 계층은 SQL Server 행 수준 보안을 사용하거나 사용하지 않고 기능을 직접 거부할 수 있습니다. 그렇지 않은 경우 저장 프로시저 또는 보기를 사용하여 보안이 활성화된 경우가 많습니다.
비즈니스 계층(서버 측)은 알려진 사용자 Microsoft Entra ID를 사용하여 저장 프로시저를 SQL Server 주체로 호출하고 데이터를 필터링합니다. 그러나 Power Apps는 현재 저장 프로시저에 연결되지 않습니다. 비즈니스 계층은 Microsoft Entra ID를 SQL Server 보안 주체로 사용하는 보기를 호출할 수도 있습니다. 이 경우 Power Apps를 사용하여 보기에 연결하여 데이터가 서버 측에서 필터링되도록 합니다. 사용자에게 보기만 노출하려면 업데이트를 위해 Power Automate 흐름이 필요할 수 있습니다.