Power Apps를 사용하여 SQL Server에 연결 하고 인증하는 방법에는 여러 가지가 있습니다. 이 문서에서는 앱에 대한 요구 사항과 일치하는 보안 접근 방식으로 SQL Server에 연결하는 방법을 선택하는 데 도움이 될 수 있는 개념을 간략하게 설명합니다.
중요합니다
보안 암시적 연결 기능은 2024년 1월에 릴리스되었습니다. Microsoft는 현재 암시적 연결을 사용하는 모든 앱이 안전한 암시적 연결로 변환하고 최종 사용자와 공유되는 연결을 해지하도록 강력히 권장합니다.
명시적, 암시적 연결 및 보안 암시적 연결 간의 차이점
SQL Server에 연결하는 Power Apps를 사용하여 앱을 만들 때마다 SQL Server에 대한 연결이 만들어집니다. 이러한 앱이 게시되고 다른 사용자와 공유되면 앱과 연결이 모두 해당 사용자에게 배포됩니다. 즉, 앱과 연결은 모두 앱이 공유되는 사용자에게 표시됩니다.
이러한 연결에 사용되는 인증 방법은 명시적 또는 암시적일 수 있습니다. 또한 이러한 연결이 명시적으로 또는 암시적으로 공유되는 것을 말할 수 있습니다.
- 명시적으로 공유된 연결은 애플리케이션의 최종 사용자가 자신의 명시적 자격 증명을 사용하여 SQL Server에 인증해야 한다는 것을 의미합니다. 일반적으로 이 인증은 Microsoft Entra 또는 Windows 인증 핸드셰이크의 일부로 백그라운드에서 발생합니다. 사용자는 인증이 언제 이루어지는지도 알지 못합니다.
- 암시적으로 공유된 연결은 사용자가 앱 작성자가 앱을 만드는 동안 데이터 원본에 연결하고 인증하는 데 사용한 계정의 자격 증명을 암시적으로 사용한다는 것을 의미합니다. 최종 사용자의 자격 증명은 인증에 사용되지 않습니다 . 최종 사용자가 앱을 실행할 때마다 작성자가 앱을 만든 자격 증명을 사용합니다.
- 안전한 암시적 공유 연결은 앱의 최종 사용자가 앱 작성자가 앱을 만드는 동안 데이터 원본에 연결하고 인증하는 데 사용한 계정의 자격 증명을 암시적으로 사용하는 시나리오를 나타냅니다. 즉, 최종 사용자의 자격 증명은 인증에 사용되지 않습니다. 대신 사용자가 앱을 실행할 때 앱 작성자가 만든 자격 증명을 사용합니다. 최종 사용자에게 연결에 대한 직접 액세스 권한이 제공되지 않으며 앱은 제한된 작업 및 테이블 집합에 대한 액세스만 허용한다는 점에 유의해야 합니다.
Power Apps용 SQL Server에서 다음 네 가지 연결 인증 유형을 사용할 수 있습니다.
| 인증 유형 | Power Apps 연결 방법 |
|---|---|
| Microsoft Entra 통합 | Explicit |
| SQL Server 인증 | 암시적/보안 암시적 |
| Windows 인증 | 암시적/보안 암시적 |
| Windows 인증(공유되지 않는) | Explicit |
암시적 연결 공유 위험
모든 새 애플리케이션은 새 보안 암시적 연결을 자동으로 사용합니다. 그러나 이전의 '암시적 연결'을 사용하는 앱에서는 앱과 해당 연결이 모두 최종 사용자에게 배포되므로 최종 사용자가 해당 연결을 기반으로 새 애플리케이션을 작성할 수 있습니다.
작성자가 보안 암시적 연결을 사용하는 경우 연결이 공유되지 않고 최종 사용자가 연결 개체를 수신하지 않음을 의미합니다. 이렇게 하면 최종 사용자 작성자가 연결을 다시 사용하여 새 앱을 만들 위험이 없습니다. 대신 앱은 앱을 인식하고 해당 특정 앱과만 통신하는 프록시 연결로 작동합니다. 프록시 연결을 사용하면 앱이 게시될 때 정의된 앱의 특정 테이블에 대한 제한된 작업(만들기, 읽기, 업데이트, 삭제)과 액세스를 허용합니다. 따라서 최종 사용자에게 권한 있는 작업 및 액세스 권한만 부여됩니다.
이전 스타일의 단순 암시적 연결은 실제로 연결 개체를 최종 사용자에게 배포합니다. 예를 들어 사용자가 볼 수 없도록 데이터를 필터링하는 앱을 만드는 경우입니다. 그러나 필터링된 데이터는 데이터베이스에 있습니다. 그러나 최종 사용자에게 특정 데이터가 표시되지 않도록 구성한 필터에 의존합니다.
이전 스타일의 단순 암시적 연결을 사용하여 앱을 배포한 후 최종 사용자는 새로 만든 앱에서 앱과 함께 배포된 연결을 사용할 수 있습니다. 새 앱에서 사용자는 애플리케이션에서 필터링한 데이터를 볼 수 있습니다. 새 보안 암시적 연결을 사용하는 것이 중요합니다.
중요합니다
이전 암시적으로 공유된 연결이 최종 사용자에게 배포되면 공유한 앱에 적용할 수 있는 제한 사항(예: 필터 또는 읽기 전용 액세스)은 최종 사용자가 만든 새 앱에 더 이상 유효하지 않습니다. 최종 사용자에게는 암시적으로 공유된 연결의 일부로 인증에서 허용하는 모든 권한이 있습니다. 따라서 보안 암시적 연결을 사용하도록 앱을 변환하는 경우 앱과 공유한 연결 도 해지해야 합니다. 관리자는 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 흐름이 필요할 수 있습니다.