연습 - Azure 서비스에 대한 공용 데이터베이스 액세스 제한

  • 7분

이 단원에서는 모든 공용 IPv4 주소의 연결 시도를 허용하는 PostgreSQL 방화벽 규칙을 Azure 서비스 허용 예외로 바꿉니다. 데이터베이스는 공용 엔드포인트를 유지합니다. 이 예외를 사용하면 이 Quarkus 애플리케이션을 포함한 Azure 서비스 및 리소스가 인증된 연결을 시도할 수 있습니다. 이 애플리케이션 또는 Container Apps 환경에 대한 액세스를 제한하지는 않습니다.

이전 연습의 AZ_* 변수를 사용하여 동일한 로컬 Bash 셸 또는 Windows의 WSL에서 계속 진행합니다. Azure가 아닌 공용 소스 네트워크에서 데이터베이스 검사를 실행합니다. Azure CLI 2.87.0 이상을 사용하고 리소스 이름 및 암호 설정을 다시 실행하지 마세요.

CLI를 사용하여 PostgreSQL 서버에 액세스

먼저 현재 클라이언트 네트워크에서 PostgreSQL 서버를 쿼리할 수 있는지 확인합니다.

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

쿼리가 이전에 만든 to-do 항목을 반환하는지 확인하세요. 이는 모든 클라이언트 네트워크가 아니라 셸의 원본 네트워크에서 연결이 확인됨을 의미합니다. 이후 테스트를 위한 정상적으로 작동하는 기준 상태를 확보할 수 있도록 방화벽을 변경하기 전에 쿼리 오류를 해결합니다.

지나치게 허용적인 방화벽 규칙 제거

새 PostgreSQL 서버를 --public-access All 만들 때 해당 공용 엔드포인트를 사용하도록 설정하고 모든 공용 IPv4 주소에 대해 하나의 방화벽 규칙을 만들었습니다.

Note

이러한 방화벽 명령은 Azure CLI 2.87.0에 도입된 매개 변수 이름을 사용합니다. --server-name는 서버를 식별하고 --name는 방화벽 규칙을 식별합니다. 별도의 az postgres flexible-server execute 명령은 여전히 서버에 --name을 사용합니다. 구문 세부 정보는 방화벽 명령 참조를 참조하세요.

계속하기 전에 실패한 방화벽 명령을 해결합니다. 거부된 명령은 방화벽을 변경하지 않습니다. 사용자가 소유한 연습 서버의 기존 규칙을 나열합니다.

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

StartIpAddress이(가) 255.255.255.255이고 0.0.0.0이(가) EndIpAddress인 규칙을 찾습니다. Name 열에서 생성된 이름은 달라집니다. 이 모듈에서 사용되는 새 서버에 대한 유일한 규칙이어야 합니다. 결과가 다른 경우 실습용 서버를 사용하고 있는지 확인하고 계속하기 전에 불일치를 해결합니다. 기존 또는 공유 서버에서 관련 없는 규칙을 삭제하지 마세요.

이 범위는 모든 공용 IPv4 원본 주소가 데이터베이스 연결을 시도할 수 있도록 허용합니다. 클라이언트에는 여전히 유효한 PostgreSQL 자격 증명이 필요합니다. 연습의 뒷부분에서 Azure 서비스 예외를 추가하기 전에 이 규칙을 제거하세요.

PostgreSQL 방화벽 업데이트를 적용하는 데 최대 5분이 걸릴 수 있습니다. 연결을 확인하기 전에 각 변경이 성공한 후 잠시 기다리십시오. 새 호출에서 CLI 쿼리를 반복하여 새 데이터베이스 연결을 테스트합니다. 애플리케이션에 대한 HTTP 요청은 별도의 애플리케이션 수준 검사입니다.

다음 명령에서 <allow-all-rule-name>를 방금 나열한 모든 주소 규칙의 실제 Name로 바꾸십시오. 꺾쇠 괄호를 제거하고 따옴표를 유지하고 해당 규칙만 삭제합니다.

az postgres flexible-server firewall-rule delete \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --name "<allow-all-rule-name>" \
    --yes

삭제가 완료되면 규칙을 다시 나열합니다.

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

이제 list 명령이 성공하면 규칙이 반환되지 않아야 합니다. 명령이 실패하거나 규칙이 남아 있는 경우 계속하기 전에 해당 결과를 해결한 후 진행합니다. 빈 목록은 구성된 규칙이 확인됨을 의미하지만 네트워크 업데이트가 전파되었음을 의미하지는 않습니다.

전파 시간이 반영될 시간을 둔 후 쿼리를 다시 실행하여 새 직접 데이터베이스 연결을 만듭니다.

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

삭제가 적용되면 새 데이터베이스 연결을 거부해야 합니다. 오류 텍스트는 클라이언트 및 네트워크 경로에 따라 달라집니다. 예를 들어 PostgreSQL은 일치하는 pg_hba.conf 항목이 없다고 보고할 수 있습니다. 특정 시간 제한 메시지를 기대하지 마세요. 삭제 직후 쿼리가 성공하면 방화벽 변경 내용이 계속 전파되고 있음을 의미할 수 있습니다.

이 규칙이 없는 단계는 변경 내용이 적용된 후 애플리케이션에서 새 데이터베이스 연결을 의도적으로 차단합니다. 애플리케이션의 HTTPS 엔드포인트는 공용으로 유지됩니다. Quarkus는 풀된 데이터베이스 연결을 사용하므로 HTTP 요청이 반드시 새 데이터베이스 연결을 열 필요는 없습니다. HTTP 상태 및 본문을 검사하지만 방화벽 전파가 완료되었다는 증거로 즉각적인 응답을 사용하지 마세요.

curl --include "https://$AZ_APP_URL/api/todos"

이 --include 옵션은 본문뿐만 아니라 HTTP 응답 헤더도 표시합니다. 기본적으로 curl은 HTTP 오류 상태를 명령 실패로 처리하지 않으므로 종료 코드에 의존하는 대신 상태를 검사합니다. 자세한 내용은 curl 설명서를 참조하세요.

Azure 서비스 예외 추가

배포된 애플리케이션이 데이터베이스에 다시 연결할 수 있도록 Azure 서비스 예외를 추가합니다.

az postgres flexible-server firewall-rule create \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --name "Allow_Azure-services" \
    --start-ip-address "0.0.0.0" \
    --end-ip-address "0.0.0.0"

시작 값과 종료 값 0.0.0.0은 PostgreSQL 방화벽 규칙에 설명된 대로 Azure 내의 모든 Azure 내부의 모든 Azure 서비스에서 이 서버로의 퍼블릭 액세스 허용 기능을 활성화합니다. 이는 개인 IP 주소 범위가 아니라 데이터베이스의 퍼블릭 엔드포인트에 대한 서비스 정의 예외입니다.

Important

이 예외는 다른 고객의 구독에 있는 Azure 리소스의 연결 시도도 허용합니다. Quarkus 애플리케이션을 식별하거나 하나의 환경, 구독 또는 테넌트에 대한 액세스를 제한하지 않습니다. 클라이언트는 여전히 인증해야 합니다. 이 연습에서는 프라이빗 네트워킹 또는 애플리케이션 전용 액세스를 구성하지 않습니다.

만들기에 성공하면 규칙을 다시 나열하세요:

az postgres flexible-server firewall-rule list \
    --server-name "$AZ_POSTGRES_SERVER_NAME" \
    --resource-group "$AZ_RESOURCE_GROUP" \
    --output table

이 새 서버의 유일한 규칙은 이제 StartIpAddress이어야 하며, EndIpAddress 및 0.0.0.0는 모두 Allow_Azure-services로 설정되어 있어야 합니다. 명령이 실패하거나 규칙이 이 결과와 일치하지 않는 경우 연결을 테스트하기 전에 불일치를 해결하십시오. 변경 내용이 적용되려면 최대 5분이 소요됩니다.

데이터베이스 및 애플리케이션 액세스 확인

전파에 시간이 걸리므로 잠시 기다린 후 Azure가 아닌 공용 원본 네트워크에 있는 로컬 개발 컴퓨터에서 새 호출로 다음 명령을 실행합니다. 초기 쿼리와 동일한 작업 중인 데이터베이스 자격 증명을 사용합니다. 다른 방화벽 규칙이 해당 원본 주소를 허용하는 경우가 없으면 데이터베이스 연결을 거부해야 합니다.

방화벽 규칙은 클라이언트가 Azure CLI인지 여부가 아니라 원본 주소를 평가합니다. 이 부정 테스트에는 Azure Cloud Shell을 사용하지 마세요. Azure 서비스 예외는 연결을 허용할 수 있습니다. 유효한 자격 증명이 있는 Azure에서 호스팅되는 클라이언트에서 쿼리가 성공했다고 해서 방화벽 업데이트가 실패했다는 뜻은 아닙니다.

az postgres flexible-server execute \
    --name "$AZ_POSTGRES_SERVER_NAME" \
    --database-name "$AZ_POSTGRES_DB_NAME" \
    --admin-user "$AZ_POSTGRES_USERNAME" \
    --admin-password="$AZ_POSTGRES_PASSWORD" \
    --querytext "select * from Todo" \
    --output table

Azure 서비스 예외가 적용될 때까지 기다린 후 배포된 애플리케이션을 통해 할 일 목록을 검색합니다. HTTP 200 상태 코드와 이전에 만든 to-do 항목이 포함된 JSON 배열이 있는지 확인합니다.

curl --include "https://$AZ_APP_URL/api/todos"

전파 기간 후에도 새 데이터베이스 연결에서 예상치 못한 상태가 계속되면 자격 증명을 변경하기 전에 실제 방화벽 규칙 및 클라이언트의 원본 네트워크를 검사합니다. HTTP 200 및 예상 JSON 데이터가 없는 애플리케이션 응답은 긍정 검사를 통과하지 못합니다.

다른 규칙이 허용하지 않으면 Azure 아닌 원본 주소의 직접 PostgreSQL 연결이 차단됩니다. 유효한 데이터베이스 자격 증명이 있는 Azure 원본 클라이언트는 계속 연결할 수 있습니다. 애플리케이션의 HTTPS API는 공용으로 유지됩니다. 이러한 검사는 애플리케이션 전용 데이터베이스 격리를 확립하지 않습니다.