보안 기능 및 작업
SQL Server 및 Azure SQL 서비스는 특히 엔터프라이즈급으로 보안을 설정하는 데 중요한 것으로 알려져 있습니다. 이 단원에서는 네트워크 보안 및 액세스 관리와 관련된 다양한 보안 기능을 알아봅니다. 다음 단원에서는 이러한 기능 중 일부를 실습합니다.
네트워크 보안
보안의 첫 번째 레이어는 네트워크를 포함합니다. 네트워킹 기능 및 작업은 Azure SQL Database와 Azure SQL Managed Instance에서 서로 다릅니다. Azure SQL Managed Instance 네트워킹 기능에 대한 자세한 내용은 Azure SQL Managed Instance의 연결 아키텍처를 참조하세요.
Azure SQL Database 네트워크 보안
Azure SQL Database에 대한 네트워크를 보호하는 경우 네 가지 주요 선택 사항이 있습니다.
- Azure 서비스에 대한 액세스 허용
- 방화벽 규칙 사용
- 가상 네트워크 규칙 사용
- Azure Private Link 사용
이러한 주요 선택 사항 외에도 모든 퍼블릭 액세스를 차단하고(Azure Private Link만 포함) 최소 TLS(전송 계층 보안) 버전을 강제 적용할 수 있습니다. 안전성은 가장 낮지만 가장 쉽게 구성하는 방법은 Azure 서비스에 대한 액세스를 허용하는 것입니다. 가장 안전한 방법은 Private Link를 사용하는 것입니다. 다음 섹션에서는 각 옵션의 기능과 각 옵션을 구성 및 유지 관리하는 방법을 다룹니다.
Azure 서비스에 대한 액세스 허용
Azure SQL Database 배포 도중 Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용을 예로 설정할 수 있습니다. 이 옵션을 선택한 경우 모든 지역 또는 구독의 모든 리소스에서 리소스 액세스 가능성을 허용합니다. 이 옵션을 사용하면 Azure를 통해 제공되는 모든 것의 연결 가능성을 허용하기 때문에 Azure SQL Database를 간편하게 실행하고 Azure Virtual Machines 또는 Azure App Service(또는 Azure Cloud Shell)와 같은 다른 서비스에 연결할 수 있습니다.
Azure 서비스에 대한 액세스를 허용하더라도 Azure 외부(예: 온-프레미스 환경)에서의 액세스는 허용되지 않습니다.
가장 안전한 구성은 Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용을 아니오로 설정하는 것입니다. 이 구성은 다음 섹션에 나오는 다양한 옵션을 사용하여 명시적으로 추가한 연결과 네트워크를 제외한 모든 연결과 네트워크를 차단합니다.
방화벽 규칙
다음 옵션은 방화벽 규칙을 적용하는 것입니다. 결과는 각 서비스(다음 이미지에서 VM(가상 머신))에 대해 연결할 수 있도록 고유한 방화벽 규칙을 추가해야 한다는 점을 제외하고 Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용과 유사할 수 있습니다. 또한 방화벽 규칙을 사용하면 온-프레미스 환경에서 머신 및 애플리케이션에 대한 규칙을 추가할 수 있으므로 온-프레미스 환경에서 Azure SQL Database 리소스에 연결할 수 있습니다.
Azure에서 연결하려면 Azure 서비스에 대한 액세스를 허용한 다음, 온-프레미스 연결 전용의 방화벽 규칙을 추가할 수도 있습니다. 앞서 언급했듯이, Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용은 모든 Azure 트래픽을 허용하기 때문에 안전하지 않습니다. 방화벽 규칙만을 사용하는 것이 좋습니다.
방화벽 규칙을 구성한 앞의 예시를 살펴보겠습니다. SSMS(SQL Server Management Studio) 같은 T-SQL(Transact-SQL)을 지원하는 도구를 사용하여 가상 네트워크 SQLDBVNET-EUS의 Azure VM에서 다음 쿼리를 실행할 수 있습니다.
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
결과는 203.0.113.1일 것입니다. 이는 Azure VM의 공용 IP 주소입니다. 방화벽 규칙을 사용하는 경우에도 모든 연결은 공개적입니다.
가상 네트워크 규칙
방화벽 규칙만 사용하려는 경우 설정이 복잡할 수 있습니다. 방화벽 규칙만 사용한다는 것은 경우에 따라 동적 IP 주소를 가질 수 있는 모든 연결에 대한 IP 주소 범위를 지정해야 한다는 의미입니다. 훨씬 쉬운 대안은 가상 네트워크 규칙을 사용하여 데이터에 액세스해야 하는 VM 또는 다른 서비스를 포함하는 특정 네트워크에서 액세스를 설정하고 관리하는 것입니다.
가상 네트워크 규칙을 사용하여 가상 네트워크에서 액세스를 구성하는 경우 해당 가상 네트워크의 모든 리소스는 Azure SQL Database 논리 서버에 액세스할 수 있습니다. 이를 통해 데이터에 액세스해야 하는 모든 고정 및 동적 IP 주소에 대한 액세스를 구성하는 과제를 간소화할 수 있습니다. 가상 네트워크 규칙을 사용하면 내부의 모든 리소스를 포함하는 하나 이상의 가상 네트워크를 지정할 수 있습니다. Azure 및 온-프레미스 지역 전체에서 네트워크를 연결하기 위해 가상 네트워크 기술을 적용할 수도 있습니다.
이 예시에서는 이전 섹션과 마찬가지로, 가상 네트워크 SQLDBVNET-EUS의 Azure VM에서 동일한 쿼리를 실행할 수 있습니다.
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
이제 결과는 Azure VM의 프라이빗 IP 주소인 10.0.0.2가 됩니다. 리소스가 가상 네트워크를 통해 연결되어 있기 때문에 Azure SQL Database 논리 서버에 대한 프라이빗 연결 설정에 한 걸음 더 가까워졌습니다.
연결을 분석하는 또 다른 일반적 전략은 DNS(Domain Name System) 계층 구조를 검사하는 것입니다. 동일한 Azure VM의 명령 프롬프트에서 다음 명령을 실행할 수 있습니다.
nslookup aw-server.database.windows.net
이 명령을 사용하여 DNS 인프라와 관련된 세부 정보를 얻을 수 있습니다. 결과는 다음과 유사합니다.
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 203.0.113.1
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
신뢰할 수 없는 답변에는 다음과 같은 몇 가지 중요한 사항이 있습니다.
- 이름:
cr2로 시작하는 엔드포인트는 퍼블릭 DNS 계층 구조의 일부입니다. 계층 구조를 너무 자세히 살펴보지는 않겠지만,cr2는 control ring 2이며 그 아래에는 여러 개의 데이터 “조각”이 있다고 가정하겠습니다. - 주소: 여기에서 반환된 IP 주소는 Azure VM의 퍼블릭 IP와 일치해야 합니다. SSMS의 최종 홉과 같은 도구가 VM의 프라이빗 IP 주소를 통과한 경우에도, VM의 공용 IP가 일부 용량을 연결하기 위해 계속해서 사용될 수 있습니다.
- 별칭: 별칭은 DNS 계층 구조 내의 다양한 포인트로, 이 경우에는 특정 데이터 “조각” 및 연결할 엔드포인트입니다.
참고 항목
이전 출력 블록에서 주소: 168.63.129.16은 Azure 플랫폼 리소스에 대한 통신 채널을 용이하게 하는 데 사용되는 가상 퍼블릭 IP 주소입니다. 이는 모든 지역 및 국가 클라우드에 적용되며 변경되지 않습니다.
SSMS를 통한 연결이 Azure VM의 프라이빗 IP 주소를 통해 제공되더라도 최종적으로는 계속해서 퍼블릭 엔드포인트를 통해 연결됩니다.
Azure SQL Database의 Private Link
퍼블릭 엔드포인트를 포함한 Azure SQL Database의 데이터베이스를 사용하여 가장 안전한 네트워크를 구성하는 방법을 살펴보았습니다. 이 SQL Database 보안 설정 방법은 다년간 사용되었습니다. 하지만 2019년에 Azure는 Azure SQL Managed Instance 배포 방식과 더욱 유사한 프라이빗 링크라는 개념으로 전환하기 시작했습니다. Azure Private Link를 사용하면 프라이빗 엔드포인트를 사용하여 SQL Database 및 기타 여러 PaaS(Platform-as-a-Service) 제품의 데이터베이스에 연결할 수 있습니다. 즉, 특정 가상 네트워크 내에 프라이빗 IP 주소가 있다는 의미입니다.
이전 예시에서는 일반 네트워킹 인프라가 변경되지 않았음을 알 수 있습니다. 따라서 가상 네트워크 규칙에서 가상 네트워크 연결 전략을 여전히 적용할 수 있습니다. 하지만 가상 네트워크 규칙을 만들 필요는 없습니다. 데이터베이스 서버에 연결해야 하는 리소스에는 엔드포인트가 있는 가상 네트워크에 대한 액세스 권한이 있어야 합니다. 이 예제에서 엔드포인트는 SQLDBVNet-EUS입니다. 프라이빗 엔드포인트를 통해 이동하는 연결만 액세스가 가능하며 다른 모든 연결(예: 인터넷)은 거부됩니다.
이 예시를 계속 진행하면 가상 네트워크 SQLDBVNet-EUS의 Azure VM에서 다음 T-SQL 명령을 다시 실행할 수 있습니다.
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
이제 결과는 이 예에 제시된 Azure VM의 프라이빗 IP 주소인 10.0.0.2일 것입니다. 가상 네트워크에서 액세스를 추가함으로써 VM으로부터 Azure SQL Database에 대한 연결이 VM의 프라이빗 IP 주소를 통해 제공되는 것처럼 보입니다. 이는 가상 네트워크 규칙을 사용한 것과 같은 결과입니다.
그러나 다음 명령을 통해 명령 프롬프트를 사용하여 DNS 계층 구조를 살펴보는 것이 좋습니다.
nslookup aw-server.database.windows.net
이전 명령을 사용할 경우 결과는 구성된 프라이빗 엔드포인트와 조금 다를 수 있습니다.
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
신뢰할 수 없는 답변에는 다음과 같은 몇 가지 중요한 사항이 있습니다.
- 이름: 이제 퍼블릭 DNS 계층 구조가 아닌 Private Link DNS만을 가리킵니다. 이는 데이터베이스 서버에 관한 정보가 덜 공개됨을 의미합니다.
- 주소: 가상 네트워크 규칙의 경우 반환되는 주소는 VM의 퍼블릭 IP 주소이지만 이제 Private Link 계층 구조 내 하나 이상의 프라이빗 IP 주소여야 합니다(하나는 Azure SQL Database의 프라이빗 엔드포인트).
- 별칭: 이름 필드와 마찬가지로 서버 이름(예:
aw-server.database.windows.net)에 연결할 수 있다는 점을 제외하면 DNS 계층 구조와 관련된 것이 전혀 없습니다.
프라이빗 엔드포인트에 연결하는 경우 ‘여전히 동일한 서버 이름을 사용하는 이유’가 궁금할 것입니다. 백 엔드에서 Azure SQL Database에 연결하는 Private Link 연결 방법만 사용하는 경우(즉, 방화벽 또는 가상 네트워크 규칙 없음) 정보는 다음과 같이 처리됩니다.
aw-server.database.windows.net- 서비스에서
aw-server.privatelink.database.net로 확인됨- 서비스에서
10.0.0.5(프라이빗 엔드포인트의 IP 주소)로 확인됨
- 서비스에서
- 서비스에서
이에 더해 서비스에서는 aw-server.database.windows.net 이외의 항목을 사용한 직접 연결을 차단합니다.
액세스 관리
네트워킹 액세스 작업이 완료되면 다음으로 고려할 레이어는 액세스 관리입니다.
역할 기반 액세스 제어
Azure SQL Database에 대한 모든 Azure 유형의 작업은 RBAC(역할 기반 액세스 제어)를 통해 제어됩니다. RBAC는 현재 Azure SQL 보안에서 분리되어 있지만 이를 구독, 리소스 그룹 및 리소스를 포함하는 범위와 함께 SQL Database에서 데이터베이스 외부의 보안 권한으로 간주할 수 있습니다. 이 권한은 Azure Portal, Azure CLI 및 Azure PowerShell의 작업에 적용됩니다. RBAC를 통해 배포, 관리 및 사용량 간 업무를 분리할 수 있습니다.
Owner 또는 Contributor와 같은 더 높은 수준의 RBAC 역할에 대한 필요성을 줄이려면 기본 제공 역할을 사용할 수 있습니다. 실제로 이러한 역할을 사용하여 특정 개인이 Azure SQL 리소스를 배포(또는 보안 정책을 관리)하도록 할 수 있지만, 다른 사용자에게 데이터베이스를 사용하거나 관리할 실질적인 액세스 권한을 부여할 수 있습니다. 예를 들어 SQL Server Contributor는 서버를 배포하고 사용자를 서버 및 데이터베이스의 관리자로 할당할 수 있습니다. Azure SQL Database에 대한 기본 제공 역할은 다음과 같습니다.
- SQL DB 기여자: 데이터베이스를 만들고 관리할 수 있지만 액세스할 수는 없음(예를 들어 연결하여 데이터를 읽을 수는 없음)
- SQL 보안 관리자: 데이터베이스 및 인스턴스의 보안 정책(예: 감사)을 관리할 수는 있지만 액세스할 수는 없습니다.
- SQL Server 기여자: 서버와 데이터베이스를 관리할 수는 있지만 액세스할 수는 없음
인증
Azure SQL 데이터베이스 논리 서버를 배포하는 동안 다음의 인증 방법을 지정할 수 있습니다.
- Microsoft Entra 인증만 사용
- SQL 및 Microsoft Entra 인증 모두 사용
- SQL 인증 사용
배포하는 동안 서버 관리자를 설정해야 합니다. Azure SQL Database의 데이터베이스의 경우 서버 관리자는 Azure SQL Database 논리 서버의 서버 수준 보안 주체입니다.
Windows 인증이 필요한 워크로드를 마이그레이션하거나 조직에서 Microsoft Entra ID를 사용하는 경우 Microsoft Entra ID를 사용할 수 있습니다. 포털 또는 명령줄 도구를 사용하여 Microsoft Entra 서버 관리자를 할당할 수 있습니다.
Microsoft Entra 전용 인증은 새 서버를 구성할 때 기본 옵션입니다. 서버 로그인은 SQL Database의 가상 master 데이터베이스에 로그인하는 Microsoft Entra 서버 보안 주체를 허용하기 위해 도입되었습니다. Microsoft Entra 사용자, 그룹 및 서비스 주체에서 Microsoft Entra 로그인을 만들 수 있습니다. Microsoft Entra 전용 인증을 사용하는 경우 SQL 인증 로그인을 만들 수 있으며 기존 로그인은 유지됩니다. 그러나 Microsoft Entra 인증 로그인 및 사용자만 논리 서버에 연결할 수 있습니다. Microsoft Entra 전용 인증에 대한 자세한 내용은 Azure SQL을 사용한 Microsoft Entra 전용 인증을 참조하세요.
조직에서 Microsoft Entra 인스턴스를 구성한 방법에 따라 다음 세 가지 방법(예: SSMS)을 사용하여 연결할 수 있습니다.
Microsoft Entra ID - 통합: 페더레이션된 도메인에서 Microsoft Entra 자격 증명을 사용하여 Windows에 로그인하는 경우 사용할 수 있는 비대화형 방법입니다.
Microsoft Entra ID - 암호: Microsoft Entra ID 관리형 도메인을 사용하여 Microsoft Entra 보안 주체 이름으로 연결할 수 있는 비대화형 메서드입니다. 설명서:
네이티브 또는 페더레이션된 Microsoft Entra 사용자에게 적용할 수 있습니다. 원시 사용자가 Microsoft Entra ID에서 명시적으로 생성되고 사용자 이름 및 암호를 사용하여 인증되는 반면, 페더레이션 사용자는 도메인이 Microsoft Entra ID와 페더레이션된 Windows 사용자입니다. 후자 방법(사용자 이름 및 암호 사용)은 사용자가 자신의 Windows 자격 증명을 사용하려 하지만 로컬 컴퓨터가 도메인과 조인되지 않은 경우(예: 원격 액세스 사용) 사용할 수 있습니다. 이 경우 Windows 사용자는 도메인 계정과 암호를 표시해 페더레이션 자격 증명을 사용하여 SQL Database 또는 Azure Synapse Analytics(이전의 SQL DW)에 인증할 수 있습니다.
Microsoft Entra ID - MFA(다단계 인증)를 사용하는 유니버설: Microsoft Entra 다단계 인증을 사용하여 단일 로그인 프로세스에 대한 조직의 수요를 충족하는 동시에 데이터에 대한 액세스를 보호하는 대화형 방법입니다.
Azure SQL Database는 몇 가지 미묘한 차이가 있습니다. 가상 master 데이터베이스, 데이터베이스 사용자 및 Microsoft Entra 계정에 대한 포함된 데이터베이스 사용자(권장)에 존재하는 로그인을 가질 수 있습니다. Azure SQL Database의 서버 관리자는 기본적으로 sysadmin 권한을 갖지만 서버 또는 데이터베이스 수준 역할을 사용하여 더 제한적인 권한을 가진 관리자를 만들 수 있습니다. 두 가지 데이터베이스 수준 역할은 가상 master 데이터베이스에만 존재하는 SQL Database에 사용할 수 있습니다.
- loginmanager: 멤버가 데이터베이스 서버에 대한 로그인을 만들 수 있도록 하는 데이터베이스 수준 역할
- dbmanager: 멤버가 데이터베이스 서버에 대한 데이터베이스를 만들고 삭제할 수 있도록 하는 데이터베이스 수준 역할
다음은 Azure SQL Database의 서버 수준 역할 목록입니다.
- ##MS_DatabaseConnector##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
마지막으로, 인증 및 권한 부여를 설정하고 구성하는 경우 다음 네 가지 지침을 따라야 합니다.
- 서버 관리자를 사용한 배포
- 필요에 따라 다른 관리자를 생성
- 관리자가 사용자 생성 가능
- SQL Server에서와 마찬가지로 액세스 권한 부여
기타 기능
일부 네트워크 및 인증 기능을 실습한 이후 모듈에서 데이터 보호, 모니터링, 로깅 및 감사에 대한 기타 기능(및 관련 작업)을 살펴보겠습니다.