다음을 통해 공유


Azure Database for PostgreSQL - 유연한 서버의 보안

적용 대상: Azure Database for PostgreSQL - 유연한 서버

여러 보안 계층을 사용하여 Azure Database for PostgreSQL - 유연한 서버 인스턴스의 데이터를 보호할 수 있습니다. 이 문서에서는 이러한 보안 옵션에 대해 간략히 설명합니다.

조직이 경쟁 우위를 확보하는 중요한 의사 결정 활동을 추진하기 위해 데이터베이스에 저장된 데이터에 점점 더 많이 의존함에 따라 견고한 데이터베이스 보안 조치의 필요성이 그 어느 때보다 중요해졌습니다. 보안 사고가 발생하면 기밀 데이터가 노출되어 조직에 평판이 손상되는 등 치명적인 결과를 초래할 수 있습니다.

정보 보호 및 암호화

Azure Database for PostgreSQL - 유연한 서버는 다음 두 가지 방법으로 데이터를 암호화합니다.

  • 전송 중인 데이터: Azure Database for PostgreSQL - 유연한 서버는 SSL/TLS(Secure Sockets Layer 및 전송 계층 보안)를 사용하여 전송 중인 데이터를 암호화합니다. 암호화는 기본적으로 적용됩니다. SSL\TLS를 사용한 연결 보안에 대한 자세한 내용은 이 설명서를 참조하세요. 보안을 강화하려면 Azure Database for PostgreSQL - 유연한 서버의 SCRAM 인증을 사용하도록 선택할 수 있습니다.

    매우 권장되지는 않지만 레거시 클라이언트 비호환성으로 인해 필요한 경우 require_secure_transport 서버 매개 변수를 OFF로 업데이트하여 Azure Database for PostgreSQL - 유연한 서버에 연결하기 위해 TLS\SSL을 사용하지 않도록 설정하는 옵션이 있습니다. ssl_max_protocol_version 서버 매개 변수를 설정하여 TLS 버전을 설정할 수도 있습니다.

  • 미사용 데이터: 스토리지 암호화의 경우 Azure Database for PostgreSQL - 유연한 서버는 FIPS 140-2 유효성 검사 암호화 모듈을 사용합니다. 쿼리가 실행되는 동안 만들어진 백업 및 임시 파일을 포함하여 데이터는 디스크에서 암호화됩니다.

    이 서비스는 Azure Storage 암호화에 포함된 AES 256비트 암호와 함께 GCM(Galois/Counter Mode) 모드를 사용하며 키는 시스템에서 관리됩니다. 이는 SQL Server 또는 Oracle 데이터베이스의 투명한 데이터 암호화와 같은 다른 미사용 암호화 기술과 유사합니다. 스토리지 암호화는 항상 켜져 있고 해제할 수 없습니다.

네트워크 보안

Azure Database for PostgreSQL - 유연한 서버를 실행하는 경우 두 가지 주요 네트워킹 옵션이 있습니다.

  • 프라이빗 액세스: 서버를 Azure 가상 네트워크에 배포할 수 있습니다. Azure Virtual Network는 안전한 개인 네트워크 통신을 제공합니다. 가상 네트워크의 리소스는 개인 IP 주소를 통해 통신할 수 있습니다. 자세한 내용은 Azure Database for PostgreSQL - 유연한 서버의 네트워킹 개요를 참조하세요.

    네트워크 보안 그룹의 보안 규칙을 사용하면 가상 네트워크 서브넷 및 네트워크 인터페이스 내외부로 이동할 수 있는 네트워크 트래픽 유형을 필터링할 수 있습니다. 자세한 내용은 네트워크 보안 그룹 개요를 참조하세요.

  • 공용 액세스: 공개 엔드포인트를 통해 서버에 액세스할 수 있습니다. 퍼블릭 엔드포인트는 공개적으로 확인할 수 있는 DNS 주소입니다. 기본적으로 모든 연결을 차단하는 방화벽을 통해 액세스할 수 있습니다.

    IP 방화벽 규칙은 각 요청의 기존 IP 주소를 기준으로 하여 데이터베이스 액세스 권한을 부여합니다. 자세한 내용은 방화벽 규칙 개요를 참조하세요.

클라우드용 Microsoft Defender 지원

오픈 소스 관계형 데이터베이스용 Microsoft Defender는 데이터베이스에 액세스하거나 악용하려는 비정상적이고 잠재적으로 유해한 시도를 나타내는 비정상적인 활동을 감지합니다. 클라우드용 Defender는 잠재적인 위협을 탐지하고 발생 시 대응할 수 있도록 비정상적인 활동에 대한 보안 경고를 제공합니다. 이 플랜을 사용하도록 설정하면 Defender for Cloud는 비정상적인 데이터베이스 액세스 및 쿼리 패턴과 의심스러운 데이터베이스 활동을 감지할 때 경고를 제공합니다.

이러한 경고는 Defender for Cloud의 보안 경고 페이지에 표시되며 다음을 포함합니다.

  • 경고를 트리거한 의심스러운 활동의 세부 정보
  • 관련 MITRE ATT&CK 전술
  • 위협을 조사하고 완화하는 방법에 권장되는 조치
  • Microsoft Sentinel을 사용하여 조사를 계속하는 옵션

클라우드용 Microsoft Defender 및 무차별 암호 대입 공격

최소한의 해킹 방법임에도 불구하고 무차별 암호 대입 공격은 가장 일반적이고 상당히 성공적인 해킹 방법 중 하나입니다, 이러한 공격의 배후에 있는 이론은 암호를 추측하려고 무한히 많은 시도를 하면 결국 암호를 맞출 수밖에 없다는 것입니다. 클라우드용 Microsoft Defender가 무차별 암호 대입 공격을 감지하면 무차별 암호 대입 공격이 일어났다는 사실을 인식하도록 경고를 트리거합니다. 또한 유효한 사용자에 대한 무차별 암호 대입 공격 또는 성공적인 무차별 암호 대입 공격으로부터 간단한 무차별 암호 대입 공격을 분리할 수 있습니다.

Microsoft Defender 플랜에서 알림을 받으려면 먼저 다음 섹션에 표시된 것처럼 Microsoft Defender를 사용하도록 설정해야 합니다.

클라우드용 Microsoft Defender에서 향상된 보안을 사용하도록 설정

  1. Azure Portal에서 왼쪽 창의 보안 메뉴로 이동합니다.
  2. 클라우드용 Microsoft Defender를 선택합니다.
  3. 오른쪽 창에서 활성화를 선택합니다.

클라우드 Defender를 사용할 수 있도록 설정하는 방법을 보여 주는 Azure Portal의 스크린샷

참고 항목

Microsoft Defender 플랜에서 "오픈 소스 관계형 데이터베이스" 기능을 사용하도록 설정한 경우 Azure Database for PostgreSQL 유연한 서버 리소스에 대해 Microsoft Defender가 기본적으로 자동으로 사용하도록 설정되는 것을 볼 수 있습니다.

액세스 관리

Azure Database for PostgreSQL - 유연한 서버 데이터베이스 액세스 권한을 대규모로 관리하는 가장 좋은 방법은 역할 개념을 사용하는 것입니다. 역할은 데이터베이스 사용자 또는 데이터베이스 사용자 그룹일 수 있습니다. 역할은 데이터베이스 개체를 소유하고 해당 개체에 대한 권한을 다른 역할에 할당하여 개체에 대한 액세스 권한이 있는 사용자를 제어할 수 있습니다. 역할의 멤버 자격을 다른 역할에 부여하여 멤버 역할이 다른 역할에 할당된 권한을 사용하도록 할 수도 있습니다. Azure Database for PostgreSQL - 유연한 서버를 사용하면 데이터베이스 사용자에게 직접 권한을 부여할 수 있습니다. 좋은 보안 사례로, 최소 애플리케이션 및 액세스 요구 사항에 따라 특정 권한 집합을 사용하여 역할을 만드는 것이 좋습니다. 그런 다음, 각 사용자에게 적절한 역할을 할당할 수 있습니다. 역할은 데이터베이스 개체에 액세스하기 위해 ‘최소 권한 모델’을 적용하는 데 사용됩니다.

Azure Database for PostgreSQL - 유연한 서버 인스턴스는 PostgreSQL이 생성하는 기본 제공 역할 외에도 세 가지 기본 역할이 정의된 상태로 생성됩니다. 이러한 역할은 다음 명령을 실행하여 확인할 수 있습니다.

SELECT rolname FROM pg_roles;

역할은 다음과 같습니다.

  • azure_pg_admin
  • azuresu
  • 관리자 역할

Azure Database for PostgreSQL - 유연한 서버 인스턴스를 만드는 동안 관리자 역할에 대한 자격 증명을 제공합니다. 이 관리자 역할은 추가 PostgreSQL 역할을 만드는 데 사용할 수 있습니다.

예를 들어 아래에서 'demouser'라는 예제 사용자/역할을 만들 수 있음


 CREATE USER demouser PASSWORD password123;

애플리케이션에서 관리자 역할을 사용하면 안 됩니다.

클라우드 기반 PaaS 환경에서는 Azure Database for PostgreSQL - 유연한 서버 슈퍼 사용자 계정에 대한 액세스가 클라우드 운영자에 의한 컨트롤 플레인 작업으로만 제한됩니다. 따라서 azure_pg_admin 계정은 의사 슈퍼 사용자 계정으로 존재합니다. 관리자 역할은 azure_pg_admin 역할의 멤버입니다.
그러나 서버 관리자 계정은 슈퍼 사용자 권한이 있고 컨트롤 플레인 작업을 수행하는 데 사용되는 azuresu 역할에 속하지 않습니다. 이 서비스는 관리되는 PaaS 서비스이므로 Microsoft만 슈퍼 사용자 역할에 속합니다.

서버의 역할 목록을 주기적으로 감사할 수 있습니다. 예를 들어 psql 클라이언트를 사용하여 연결하고, 다른 역할 만들기, 데이터베이스 만들기, 복제 등과 같은 권한과 함께 모든 역할을 나열하는 pg_roles 테이블을 쿼리할 수 있습니다.


select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname        | demouser
rolsuper       | f
rolinherit     | t
rolcreaterole  | f
rolcreatedb    | f
rolcanlogin    | f
rolreplication | f
rolconnlimit   | -1
rolpassword    | ********
rolvaliduntil  |
rolbypassrls   | f
rolconfig      |
oid            | 24827

Important

최근 Azure Database for PostgreSQL 유연한 서버에서 CAST 명령을 만드는 기능이 활성화되었습니다. CREATE CAST 문을 실행하려면 사용자가 azure_pg_admin 그룹의 구성원이어야 합니다. 현재로서는 CAST를 생성한 후에는 삭제할 수 없습니다.

또한 Azure Database for PostgreSAL - 유연한 서버를 사용해 Azure Database for PostgreSQL - 유연한 서버에서 감사 로깅을 사용하여 데이터베이스의 활동을 추적할 수 있습니다.

스키마 액세스 제어

Azure Database for PostgreSQL - 유연한 서버에 새로 만든 데이터베이스에는 모든 데이터베이스 사용자 및 역할이 개체를 만들 수 있도록 허용하는 기본 권한 집합이 데이터베이스의 공용 스키마에 있습니다. Azure Database for PostgreSQL - 유연한 서버 인스턴스에서 만든 데이터베이스에 대한 애플리케이션 사용자 액세스를 더 잘 제한하려면 이러한 기본 공용 권한을 취소하는 것이 좋습니다. 이렇게 하면 데이터베이스 사용자에 대해 보다 세분화된 방식으로 특정 권한을 부여할 수 있습니다. 예시:

  • 애플리케이션 데이터베이스 사용자가 공용 스키마에서 개체를 만들지 못하도록 하려면 public 역할에서 public 스키마에 대한 만들기 권한을 취소합니다.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;
    
  • 다음으로 새 데이터베이스를 만듭니다.

    CREATE DATABASE Test_db;
    
  • 이 새 데이터베이스의 PUBLIC 스키마에서 모든 권한을 취소합니다.

    REVOKE ALL ON DATABASE Test_db FROM PUBLIC;
    
  • 애플리케이션 DB 사용자에 대한 사용자 지정 역할 만들기

    CREATE ROLE Test_db_user;
    
  • 이 역할을 가진 데이터베이스 사용자에게 데이터베이스에 연결할 수 있는 권한을 부여합니다.

    GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
    GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;
    
  • 데이터베이스 사용자 만들기

    CREATE USER user1 PASSWORD 'Password_to_change'
    
  • 사용자에게 연결 및 선택 권한이 있는 역할 할당

    GRANT Test_db_user TO user1;
    

이 예제에서 사용자 user1은 테스트 데이터베이스 Test_db에 연결할 수 있고 모든 권한을 가지지만, 서버의 다른 DB에는 연결할 수 없습니다. 이 사용자\역할에 해당 데이터베이스 및 해당 개체에 대한 ALL PRIVILEGES를 부여하는 대신, SELECT,INSERT,EXECUTE 등과 같은 보다 선택적인 권한을 부여하는 것이 좋습니다. PostgreSQL 데이터베이스의 권한에 대한 자세한 내용은 PostgreSQL 문서에서 GRANTREVOKE 명령을 참조하세요.

PostgreSQL 15의 공용 스키마 소유권 변경

Postgres 버전 15부터 공용 스키마의 소유권이 새로운 pg_database_owner 역할로 변경되었습니다. 이를 통해 모든 데이터베이스 소유자는 데이터베이스의 공용 스키마를 소유할 수 있습니다.
자세한 내용은 PostgreSQL 릴리스 정보에서 확인할 수 있습니다.

PostgreSQL 16 변경 내용과 역할 기반 보안

PostgreSQL 데이터베이스 역할에는 해당 권한을 정의하는 많은 특성이 있을 수 있습니다. 이러한 특성 중 하나는 사용자 및 역할의 PostgreSQL 데이터베이스 관리에 중요한 CREATEROLE 특성입니다. PostgreSQL 16에서는 이 특성에 중요한 변경 내용이 있습니다. PostgreSQL 16에서 CREATEROLE 특성을 가진 사용자는 더 이상 모든 역할의 멤버 자격을 다른 사용자에게 전달할 수 없습니다. 대신 다른 사용자와 마찬가지로 이 특성이 없으면 ADMIN OPTION을 소유한 역할의 멤버 자격만 전달할 수 있습니다. 또한 PostgreSQL 16에서는 CREATEROLE 특성을 통해 슈퍼 사용자가 아닌 사용자는 새 사용자를 프로비전할 수 있지만, 직접 생성한 사용자만 삭제할 수 있습니다. CREATEROLE 특성을 가진 사용자가 생성하지 않은 사용자를 삭제하려고 하면 오류가 발생합니다.

PostgreSQL 16에는 새롭고 향상된 기본 제공 역할도 도입되었습니다. PostgreSQL 16의 새 pg_use_reserved_connections 역할을 사용하면 reserved_connections를 통해 예약된 연결 슬롯을 사용할 수 있습니다. pg_create_subscription 역할을 통해 슈퍼 사용자는 구독을 만들 수 있습니다.

Important

Azure Database for PostgreSQL - 유연한 서버에서는 사용자가 모든 데이터(테이블, 뷰, 시퀀스)를 쓸 수 있는 pg_write_all_data 특성을 부여하는 것을 허용하지 않습니다. 이는 명시적으로 부여되지 않은 경우에도 해당 개체에 대한 INSERT, UPDATE 및 DELETE 권한과 모든 스키마에 대한 USAGE 권한을 갖는 것과 같습니다. 해결 방법으로 데이터베이스 및 개체별로 보다 한정된 수준에서 유사한 권한을 부여하는 것이 좋습니다.

행 수준 보안

RLS(행 수준 보안)는 데이터베이스 관리자가 하나 이상의 역할에 대해 특정 데이터 행이 표시되고 작동하는 방식을 제어하는 정책을 정의할 수 있도록 하는 Azure Database for PostgreSQL - 유연한 서버 보안 기능입니다. 행 수준 보안은 Azure Database for PostgreSQL - 유연한 서버 데이터베이스 테이블에 적용할 수 있는 추가 필터입니다. 사용자가 테이블에서 작업을 수행하려고 하면 쿼리 조건 또는 기타 필터링 전에 이 필터가 적용되고 보안 정책에 따라 데이터 범위가 좁아지거나 거부됩니다. SELECT, INSERT, UPDATEDELETE와 같은 특정 명령에 대한 행 수준 보안 정책을 만들고 모든 명령에 대해 지정할 수 있습니다. 행 수준 보안의 사용 사례에는 PCI 규격 구현, 분류된 환경, 공유 호스팅/다중 테넌트 애플리케이션이 포함됩니다.

SET ROW SECURITY 권한이 있는 사용자만 테이블에 행 보안 권한을 적용할 수 있습니다. 테이블 소유자는 테이블에서 행 보안을 설정할 수 있습니다. OVERRIDE ROW SECURITY와 같이 현재는 암시적 권한입니다. 행 수준 보안은 기존 GRANT 권한을 재정의하지 않으며 보다 세분화된 제어 수준을 추가합니다. 예를 들어 지정된 사용자가 행을 제공할 수 있도록 ROW SECURITY FOR SELECT를 설정하면 해당 사용자에게 해당 열 또는 테이블에 대한 SELECT 권한도 있는 경우에만 해당 사용자에게 액세스 권한이 부여됩니다.

다음은 사용자가 만든 "관리자" 역할의 멤버만 특정 계정의 행에만 액세스할 수 있도록 하는 정책을 만드는 방법을 보여 주는 예제입니다. 다음 예제의 코드는 PostgreSQL 설명서에서 공유되었습니다.

CREATE TABLE accounts (manager text, company text, contact_email text);

ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;

CREATE POLICY account_managers ON accounts TO managers
    USING (manager = current_user);

USING 절은 암시적으로 WITH CHECK 절을 추가하여 관리자 역할의 멤버가 다른 관리자에 속한 행에 대해 SELECT, DELETE 또는 UPDATE 작업을 수행할 수 없고 다른 관리자에 속한 새 행을 INSERT할 수 없도록 합니다. 다음 예와 같이 DROP POLICY 명령을 사용하여 행 보안 정책을 삭제할 수 있습니다.



DROP POLICY account_managers ON accounts;

정책을 삭제했더라도 역할 관리자는 여전히 다른 관리자에 속한 데이터를 볼 수 없습니다. 이는 계정 테이블에서 행 수준 보안 정책이 여전히 사용하도록 설정되어 있기 때문입니다. 행 수준 보안이 기본적으로 사용하도록 설정된 경우 PostgreSQL은 기본 거부 정책을 사용합니다. 아래 예와 같이 행 수준 보안을 사용하지 않도록 설정할 수 있습니다.

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

행 수준 보안 무시

PostgreSQL에는 역할에 할당할 수 있는 BYPASSRLSNOBYPASSRLS 권한이 있습니다. NOBYPASSRLS가 기본적으로 할당됩니다. Azure Database for PostgreSQL의 새로 프로비전된 서버를 사용하면 행 수준 보안 권한을 무시하는 유연한 서버(BYPASSRLS)가 다음과 같이 구현됩니다.

  • Postgres 16 이상 버전의 서버에 대해서는 표준 PostgreSQL 16 동작을 따릅니다. azure_pg_admin 관리자 역할로 만들어진 비관리자를 통해 필요에 따라 BYPASSRLS 특성\권한이 있는 역할을 만들 수 있습니다.
  • Postgres 15 이하 버전의 서버용. , azure_pg_admin 사용자를 사용하여 BYPASSRLS 권한이 필요한 관리 작업을 수행할 수 있지만, 클라우드 기반 PaaS PostgreSQL 서비스에서 일반적으로 관리 사용자 역할에는 슈퍼 사용자 권한이 없으므로 BypassRLS 권한이 있는 사용자(관리자가 아님)를 만들 수 없습니다.

암호 업데이트

보안을 강화하려면 관리자 암호와 데이터베이스 사용자 암호를 주기적으로 바꿔 사용하는 것이 좋습니다. 대문자와 소문자, 숫자 및 특수 문자를 사용하여 강한 암호를 사용하는 것이 좋습니다.

SCRAM 사용

SCRAM(Salted Challenge Response Authentication Mechanism)은 무지개 테이블 공격, 중간자(man-in-the-middle) 공격 및 저장된 암호 공격을 방지하는 몇 가지 주요 보안 기능을 추가하는 동시에 ASCII가 아닌 문자가 포함된 여러 해시 알고리즘 및 암호에 대한 지원을 추가하여 암호 기반 사용자 인증의 보안을 크게 향상합니다.

SCRAM 인증에서 클라이언트는 ID 증명을 생성하기 위해 암호화 작업 수행에 참여합니다. 따라서 SCRAM 인증은 대부분의 경우 애플리케이션 서버인 클라이언트에 계산 비용의 일부를 오프로드합니다. 따라서 더 강력한 해시 알고리즘 외에도 SCRAM을 채택하면 암호 해시를 계산하기 위한 서버의 CPU 오버로드를 보호하여 PostgreSQL에 대한 DDoS(분산 서비스 거부) 공격으로부터 보호할 수 있습니다.

클라이언트 드라이버가 SCRAM을 지원하는 경우 SCRAM을 scram-sha-256과 기본값 md5로 사용하여 Azure Database for PostgreSQL - 유연한 서버에 대한 액세스를 설정할 수 있습니다.

관리자 암호 다시 설정

관리자 암호는 방법 가이드에 따라 다시 설정합니다.

데이터베이스 사용자 암호 업데이트

데이터베이스 사용자 암호는 클라이언트 도구를 사용하여 업데이트할 수 있습니다.
예를 들면 다음과 같습니다.

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Azure Policy 지원

Azure Policy를 사용하면 조직의 표준을 적용하고 규정 준수를 대규모로 평가할 수 있습니다. 리소스별 정책별 세분성으로 드릴다운할 수 있는 기능을 사용하여 환경의 전체 상태를 평가할 수 있는 집계된 보기가 규정 준수 대시보드를 통해 제공됩니다. 또한 기존 리소스에 대한 대량 수정 및 새 리소스에 대한 자동 수정을 통해 리소스를 규정 준수 상태로 전환할 수 있습니다.

기본 제공 정책 정의

기본 제공 정책은 Microsoft에서 개발 및 테스트하여 정책이 일반적인 표준 및 모범 사례를 충족하도록 보장하며 추가 구성없이 신속하게 배포되므로 표준 규정 준수 요구 사항에 적합합니다. 기본 제공 정책은 널리 인식되는 표준 및 규정 준수 프레임워크를 포함하는 경우가 많습니다.

아래 섹션에서는 Azure Database for PostgreSQL - 유연한 서버에 대한 Azure Policy 기본 제공 정책 정의의 인덱스를 제공합니다. 원본 열의 링크를 사용하여 Azure Policy GitHub 리포지토리에서 원본을 봅니다.

이름(Azure Portal) 설명 효과 버전(GitHub)
PostgreSQL 유연한 서버에 대해 Microsoft Entra 관리자를 프로비전해야 합니다. Microsoft Entra 인증을 사용하도록 설정하기 위해 PostgreSQL 유연한 서버에 대한 Microsoft Entra 관리자 프로비전을 감사합니다. Microsoft Entra 인증을 사용하면 데이터베이스 사용자 및 기타 Microsoft 서비스의 권한을 간편하게 관리하고 ID를 한 곳에서 집중적으로 관리할 수 있습니다. AuditIfNotExists, 사용 안 함 1.0.0
PostgreSQL 유연한 서버에 대해 PgAudit를 사용한 감사를 활성화해야 합니다. 이 정책은 pgaudit가 활성화되지 않은 환경에서 PostgreSQL 유연한 서버를 감사하는 데 도움이 됩니다. AuditIfNotExists, 사용 안 함 1.0.0
PostgreSQL 유연한 서버에 대해 연결 제한을 활성화해야 합니다. 이 정책은 연결 제한이 활성화되지 않은 환경에서 PostgreSQL 유연한 서버를 감사하는 데 도움이 됩니다. 이 설정은 잘못된 암호 로그인 실패가 너무 많을 경우 IP당 임시 연결 제한을 사용하도록 설정합니다. AuditIfNotExists, 사용 안 함 1.0.0
Log Analytics 작업 영역에 PostgreSQL 유연한 서버에 대한 진단 설정을 배포합니다. 이 진단 설정이 누락된 PostgreSQL 유연한 서버가 생성되거나 업데이트될 때 PostgreSQL 유연한 서버에 대한 진단 설정을 배포하여 지역별 Log Analytics 작업 영역으로 스트리밍합니다. DeployIfNotExists, 사용 안 함 1.0.0
PostgreSQL 유연한 서버에 대한 연결 끊김을 기록해야 합니다. 이 정책은 log_disconnections를 활성화하지 않은 환경에서 PostgreSQL 유연한 서버를 감사하는 데 도움이 됩니다. AuditIfNotExists, 사용 안 함 1.0.0
PostgreSQL 유연한 서버에 대해 SSL 연결 적용을 활성화해야 합니다. Azure Database for PostgreSQL은 SSL(Secure Sockets Layer)을 사용하여 Azure Database for PostgreSQL 유연한 서버를 클라이언트 애플리케이션에 연결하는 것을 지원합니다. 데이터베이스 유연한 서버와 클라이언트 애플리케이션 간 SSL 연결을 적용하면 서버와 애플리케이션 간 데이터 스트림을 암호화함으로써 '메시지 가로채기(man in the middle)' 공격으로부터 보호하는 데 도움이 됩니다. 이 구성을 적용하면 PostgreSQL 유연한 서버에 액세스할 때 항상 SSL을 사용하도록 설정됩니다. AuditIfNotExists, 사용 안 함 1.0.0
Azure Database for PostgreSQL 유연한 서버에 대해 지역 중복 백업을 사용하도록 설정해야 합니다. Azure Database for PostgreSQL 유연한 서버를 사용하면 데이터베이스 서버에 대한 중복성 옵션을 선택할 수 있습니다. 서버가 호스트되는 지역 내에 저장될 뿐만 아니라 지역 장애 발생 시 복구 옵션을 제공하기 위해 쌍을 이루는 지역에도 복제되는 데이터가 있는 지역 중복 백업 스토리지로 설정할 수 있습니다. 백업을 위한 지역 중복 스토리지 구성은 서버 생성 중에만 허용됩니다. 감사, 사용 안 함 1.0.0
PostgreSQL 유연한 서버에 대해 로그 검사점을 사용하도록 설정해야 합니다. 이 정책은 log_checkpoints 설정이 활성화되지 않은 환경에서 PostgreSQL 유연한 서버를 감사하는 데 도움이 됩니다. AuditIfNotExists, 사용 안 함 1.0.0
PostgreSQL 유연한 서버에 대해 로그 연결을 사용하도록 설정해야 합니다. 이 정책은 log_connections 설정이 활성화되지 않은 환경에서 PostgreSQL 유연한 서버를 감사하는 데 도움이 됩니다. AuditIfNotExists, 사용 안 함 1.0.0
PostgreSQL 유연한 서버는 고객 관리형 키를 사용하여 미사용 데이터를 암호화해야 합니다. 고객 관리형 키를 사용하여 PostgreSQL 유연한 서버의 미사용 데이터 암호화를 관리합니다. 기본적으로 저장 데이터는 서비스 관리형 키를 사용하여 암호화되지만, 일반적으로 규정 준수 표준을 충족하려면 고객 관리형 키가 필요합니다. 고객 관리형 키를 사용하면 사용자가 만들고 소유한 Azure Key Vault 키를 사용하여 데이터를 암호화할 수 있습니다. 순환 및 관리를 포함하여 키의 수명 주기를 고객이 모두 제어하고 책임져야 합니다. 감사, 거부, 사용 안 함 1.0.0
PostgreSQL 유연한 서버는 TLS 버전 1.2 이상을 실행해야 합니다. 이 정책은 TLS 버전 1.2 미만으로 실행되는 환경에서 PostgreSQL 유연한 서버를 감사하는 데 도움이 됩니다. AuditIfNotExists, 사용 안 함 1.0.0
PostgreSQL 유연한 서버에서 프라이빗 엔드포인트를 사용하도록 설정해야 합니다. 프라이빗 엔드포인트 연결은 Azure Database for PostgreSQL에 대한 프라이빗 연결을 사용하도록 설정하여 보안 통신을 강화합니다. 알려진 네트워크에서 들어오는 트래픽에만 액세스할 수 있고 Azure 내부를 비롯한 다른 IP 주소의 액세스를 차단하도록 프라이빗 엔드포인트 연결을 구성합니다. AuditIfNotExists, 사용 안 함 1.0.0

사용자 지정 정책 정의

사용자 지정 정책은 고유한 보안 정책 또는 규정 준수 의무를 포함하여 조직의 특정 요구 사항에 맞게 정확하게 조정될 수 있습니다. 사용자 지정 정책을 사용하면 정책 논리 및 매개 변수를 완벽하게 제어할 수 있으므로 정교하고 세분화된 정책 정의를 사용할 수 있습니다.