ORA-24256 해결: 네트워크 ACL 설정 오류 점검

ORA-24256 해결: 네트워크 ACL 설정 오류 점검

ORA-24256은 대체로 DB에서 외부 네트워크(HTTP/HTTPS, SMTP, TCP 등)로 나가려는 시도 중 네트워크 ACL(Access Control List) 설정이 맞지 않아 발생하는 오류입니다. 일반오류형(확장형 매뉴얼) 흐름으로, 운영 환경에서 바로 확인 가능한 점검과 복구 절차를 정리합니다.

실무 기준으로 보면
ORA-24256은 “네트워크가 안 된다”가 아니라 “DB 사용자에게 네트워크 권한이 없다/잘못 매핑됐다”에 가깝습니다.
즉, OS 방화벽이나 라우팅 문제를 보기 전에 ACL 매핑과 권한을 먼저 확인하는 게 시간을 절약합니다.

개요

Oracle은 보안 강화를 위해 DB 내부에서 외부 네트워크로 연결하는 기능(예: UTL_HTTP, UTL_SMTP, UTL_TCP)을 기본적으로 제한하고, ACL로 허용 대상(호스트/포트)과 주체(스키마)를 명시적으로 부여하도록 설계되어 있습니다. ACL이 누락되거나 중복되거나, 권한이 잘못 부여되면 ORA-24256 같은 네트워크 ACL 관련 오류가 발생합니다.

환경

• DB: Oracle Database (11g 이후 전반, 19c/21c 환경에서 특히 자주 확인)
• 기능: DB 내부에서 외부 호출(HTTP/HTTPS API, SMTP 메일, TCP 소켓 등)
• 주요 패키지: UTL_HTTP, UTL_SMTP, UTL_TCP, DBMS_NETWORK_ACL_ADMIN

증상

대표적인 발생 패턴은 아래와 같습니다.

• PL/SQL에서 외부 API 호출 시 실패(UTL_HTTP 사용)
• DB에서 메일 발송 시 실패(UTL_SMTP 사용)
• 소켓 통신 시 실패(UTL_TCP 사용)
• 오류 로그에 ORA-24256이 포함되어 ACL/권한 문제로 의심되는 상황

-- 예시(형태)
ORA-24256: ... (네트워크 ACL 관련 오류)
ORA-24247: network access denied by access control list (같이 동반되는 경우가 많음)

포인트
ORA-24247(ACL로 거부)와 함께 나타나는 경우가 흔합니다.
ORA-24256이 단독으로 보이더라도, 실질적인 원인은 ACL 매핑/권한 설정에서 찾는 경우가 많습니다.

1차 점검

가장 먼저 “어떤 계정이, 어디로, 어떤 포트로 나가려 했는지”를 확정해야 합니다. 이 3가지가 확정되지 않으면 ACL을 만들어도 빗나갈 가능성이 큽니다.

점검 항목	확인 포인트
호출 주체(스키마)	프로시저 실행 계정(OWNER), 프록시/권한 위임 여부, 잡(Job) 실행 계정
대상 호스트	도메인/아이피, 와일드카드 적용 필요 여부(서브도메인 포함)
대상 포트	HTTP(80), HTTPS(443), SMTP(25/587) 등 실제 포트 범위
네임 리졸브	DB 서버에서 DNS가 제대로 되는지(호스트명 사용 시)
네트워크 레벨 차단	OS 방화벽/보안장비가 막는지(ACL 설정 후에도 실패한다면 의심)

실무 팁
“ACL은 맞는데도 안 된다”는 케이스의 상당수는 DNS/방화벽/프록시 문제입니다.
다만 ORA-24256이 보이는 순간만큼은 우선순위를 ACL 점검으로 두는 게 일반적으로 빠릅니다.

심화 분석

ORA-24256을 유발하는 대표적인 ACL 이슈는 아래 3가지로 압축됩니다.

• ACL 누락: 대상 호스트/포트에 매핑된 ACL이 없거나, 스키마 권한이 없음
• ACL 중복/충돌: 같은 호스트/포트에 여러 ACL이 엮여 기대와 다른 룰이 적용
• 권한 종류 불일치: 필요 권한(connect/resolve)이 빠짐 또는 다른 스키마에만 부여됨

현재 ACL 상태 확인(조회)

아래 조회로 “어떤 ACL이 어떤 호스트/포트에 붙어 있는지”부터 확인합니다.

-- 호스트/포트 매핑 확인
SELECT host, lower_port, upper_port, acl
FROM   dba_network_acls
ORDER  BY host, lower_port, upper_port;

-- ACL에 부여된 권한(주체/권한 종류) 확인
SELECT acl, principal, privilege, is_grant, invert
FROM   dba_network_acl_privileges
ORDER  BY acl, principal, privilege;

운영 환경에서는
“원칙상 최소 권한”이 중요합니다.
무작정 * 호스트나 광범위 포트를 열기보다, 업무에 필요한 호스트/포트만 열고 스키마도 제한하는 편이 안전합니다.

복구

아래는 가장 흔한 복구 패턴(예: 특정 스키마가 특정 API 서버의 443으로 나가야 하는 상황) 기준의 예시입니다. 실제 적용 전, 호스트/포트/스키마를 운영 환경 값으로 교체하세요.

1) 필요한 권한(connect, resolve) 부여

BEGIN
  -- 예시: APPUSER 스키마가 api.example.com (443)로 나가야 하는 경우
  DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
    host => 'api.example.com',
    lower_port => 443,
    upper_port => 443,
    ace => xs$ace_type(
      privilege_list => xs$name_list('connect','resolve'),
      principal_name => 'APPUSER',
      principal_type => xs_acl.ptype_db
    )
  );
END;
/
COMMIT;

주의
Oracle 버전/패치 레벨에 따라 ACL 관리 API가 다르게 쓰이는 환경이 있습니다.
위 예시는 12c 이후에서 흔히 쓰는 ACE 기반 방식이며, 기존 ACL 파일 기반(CREATE_ACL/ASSIGN_ACL) 환경이라면 절차가 달라질 수 있습니다.

2) 적용 확인(간단 테스트)

-- UTL_HTTP 예시(업무에 맞는 테스트로 대체)
DECLARE
  l_req  UTL_HTTP.req;
  l_resp UTL_HTTP.resp;
  l_line VARCHAR2(32767);
BEGIN
  l_req := UTL_HTTP.begin_request('https://api.example.com/health');
  l_resp := UTL_HTTP.get_response(l_req);
  UTL_HTTP.read_line(l_resp, l_line, TRUE);
  UTL_HTTP.end_response(l_resp);
END;
/

HTTPS 호출이 계속 실패한다면
ACL이 아니라 지갑(Wallet) 인증서, TLS 정책, 프록시 설정 문제일 수 있습니다.
이 경우 ORA-24256이 아닌 다른 SSL/TLS 관련 오류가 함께 보이는지 로그를 확인하세요.

재발 방지

• ACL 표준 수립: 서비스별(메일/API/내부연동) 허용 호스트/포트/스키마를 문서화
• 최소 권한 유지: 필요한 스키마만, 필요한 호스트/포트만 열기
• 변경관리 적용: 신규 연동 추가 시 “ACL 변경 → 테스트 → 승인” 절차를 릴리즈 프로세스에 포함
• 점검 쿼리 상시화: DBA_NETWORK_ACLS, DBA_NETWORK_ACL_PRIVILEGES 결과를 정기 점검
• 운영 로그 확보: 실패 시점의 스키마/호스트/포트/패키지 호출 경로가 남도록 로깅 강화

실제 사용 시
“급해서 전체 허용”을 한 번 열어버리면, 나중에 닫기가 매우 어렵습니다.
처음부터 업무 단위로 ACL을 쪼개고, 변경 기록을 남기는 방식이 장기적으로 운영 비용을 줄입니다.