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 스토리지 암호화에 포함된 AES 256비트 암호화를 사용하며, 키는 시스템에서 관리됩니다. 이는 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 - 유연한 서버 인스턴스는 3개의 기본 역할이 정의된 상태로 만들어집니다. 이러한 역할은 다음 명령을 실행하여 확인할 수 있습니다.

SELECT rolname FROM pg_roles;
  • azure_pg_admin

  • azuresu

  • 관리자 역할

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

postgres=> CREATE USER demouser PASSWORD 'password123';

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

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

참고 항목

특정 암시적 캐스트 만들기와 같은 슈퍼 사용자 전용 권한 수는 azure_pg_admin 역할이 PostgreSQL 슈퍼 사용자 역할의 권한에 맞지 않으므로 Azure Database for PostgreSQL - 유연한 서버에서 사용할 수 없습니다.

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

postgres=> \x
Expanded display is on.
postgres=> 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

또한 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 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 역할을 통해 슈퍼 사용자는 구독을 만들 수 있습니다.

행 수준 보안

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을 지원하는 경우 SCRAM을 scram-sha-256과 기본값 md5로 사용하여 Azure Database for PostgreSQL - 유연한 서버에 대한 액세스를 설정할 수 있습니다.

관리자 암호 다시 설정

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

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

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

postgres=> ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE