OpenSearch 데모 인증서(Example Com Inc. Root CA), 내부망이면 괜찮을까?

 

 

내부망에 로그 모니터링용으로 OpenSearch를 올려두고 정기 스캔을 돌리면 거의 매번 올라오는 항목이 있습니다.

SSL Certificate Cannot Be Trusted (Plugin ID: 51192)

담당 부서에 전달하면 대체로 이런 답이 돌아옵니다.

내부 개발자만 쓰는 시스템이라 공인 인증서는 의도적으로 안 쓰고 있습니다.

틀린 말은 아닙니다. 내부 도메인은 애초에 공인 CA에서 발급이 안 되는 경우도 많고, 사설 인증서를 쓰는 내부 시스템은 어디에나 있습니다. 그래서 "그럼 예외 처리"로 넘어가기 쉽습니다.

그런데 OpenSearch의 기본 인증서는 일반적인 사설 인증서와 성격이 다릅니다. 발급자가 Example Com Inc. Root CA로 찍혀 있다면 특히 그렇습니다.

 

이 글에서는 왜 이 건이 "자체 서명이라 경고가 뜬다" 수준이 아닌지, "내부용이라 괜찮다"는 답변을 어떻게 검토해야 하는지, 그리고 사내 사설 CA가 없는 환경에서 어디까지 조치할 수 있는지를 정리했습니다.

 

---

🎯 어떤 항목으로 탐지되나

데모 인증서를 그대로 쓰고 있으면 보통 세 건이 함께 올라옵니다.

플러그인	ID	탐지 사유
SSL Certificate Cannot Be Trusted	51192	알려진 공인 CA가 발급한 인증서가 아님
SSL Self-Signed Certificate	57582	체인 최상단이 자체 서명 인증서
SSL Certificate with Wrong Hostname	45411	인증서 CN이 node-0.example.com, SAN은 localhost와 루프백뿐

45411까지 같이 떠 있다면 데모 인증서일 가능성이 매우 높습니다. 실제 서버 호스트명이 node-0.example.com일 리는 없으니까요.

---

🧩 문제의 본질은 "자체 서명"이 아닙니다

여기서 한 번 짚고 가야 할 게 있습니다. 인증서 파일에는 공개키만 들어 있습니다. 인증서 자체는 배포하라고 만든 물건이라, 공개되는 것이 전혀 문제가 되지 않습니다.

구분	내용물	공개 여부
인증서 *.pem	공개키 + 주체·발급자 정보 + CA 서명	공개해도 무방
개인키 *-key.pem	실제 복호화·서명에 사용되는 비밀값	절대 공개 불가

문제는 OpenSearch의 데모 구성이 인증서와 개인키를 한 세트로 묶어 배포 패키지에 담아 배포한다는 점입니다. 설치하면 config 디렉터리에 아래 다섯 개 파일이 생성됩니다.

파일	종류	비고
root-ca.pem	CA 인증서	공개키
esnode.pem	노드 인증서	공개키
esnode-key.pem	노드 개인키	배포 패키지에 포함
kirk.pem	관리자 클라이언트 인증서	공개키
kirk-key.pem	관리자 개인키	배포 패키지에 포함

기동 로그의 파일 권한 경고에서도 다섯 개가 그대로 확인됩니다.

[WARN][o.o.s.OpenSearchSecurityPlugin] File .../config/kirk.pem has insecure file permissions (should be 0600)
[WARN][o.o.s.OpenSearchSecurityPlugin] File .../config/esnode.pem has insecure file permissions (should be 0600)
[WARN][o.o.s.OpenSearchSecurityPlugin] File .../config/root-ca.pem has insecure file permissions (should be 0600)
[WARN][o.o.s.OpenSearchSecurityPlugin] File .../config/esnode-key.pem has insecure file permissions (should be 0600)
[WARN][o.o.s.OpenSearchSecurityPlugin] File .../config/kirk-key.pem has insecure file permissions (should be 0600)

즉 모든 설치 환경이 같은 개인키를 쓰고 있습니다. 누구나 OpenSearch를 내려받으면 그 키를 손에 넣을 수 있으니, 사실상 공개된 개인키입니다.

발급자 DN도 고정값입니다. 공식 개발자 가이드에 데모 인증서 생성 명령이 그대로 실려 있습니다.

/DC=com/DC=example/O=Example Com Inc./OU=Example Com Inc. Root CA/CN=Example Com Inc. Root CA

💡 데모 설치 스크립트를 실행하면 첫 줄에 이런 경고가 출력됩니다. ** Warning: Do not use on production or public reachable systems ** 사내 보안 기준이 아니라 제조사가 직접 붙여둔 문구입니다.

---

🔓 개인키가 공개되면 무슨 일이 생기나

 

경로	성립 조건	결과
① 서버 위장 5601 / 9200	동일 네트워크에서 트래픽을 경유시킬 수 있을 것 (ARP·DNS 스푸핑 등)	공개된 esnode-key.pem으로 정상 서버와 동일한 인증서를 제시. 이용자는 위장 여부를 구분할 수 없음 → 로그인 계정·세션 탈취
② 노드 위장 가입 9300	Transport 포트에 도달 가능할 것	데모 노드 인증서는 clientAuth를 겸하고 기본 nodes_dn에 등재되어 있음 → 악성 노드가 클러스터에 합류, 전체 인덱스 접근
③ 관리자 권한 탈취 kirk 인증서	admin_dn에 CN=kirk가 남아 있을 것	공개된 kirk-key.pem만으로 클러스터 전권 획득 → 로그 열람·삭제·변조

여기서 과장하면 안 되는 부분

보고서를 쓸 때 두 가지는 정확하게 구분해 두는 편이 좋습니다. 과장했다가 되받아치면 지적 전체의 신뢰도가 떨어집니다.

첫째, 루트 CA의 개인키는 배포되지 않습니다. 데모 인증서 생성 절차를 보면 인증서를 발급한 뒤 root-ca-key.pem과 임시 키를 삭제하도록 되어 있고, 실제 설치본에도 없습니다. 따라서 공격자가 임의의 새 인증서를 발급할 수는 없습니다. admin_dn에서 CN=kirk를 제거하는 조치가 유효한 것도 이 때문입니다.

둘째, "패킷만 뜨면 다 복호화된다"는 아닙니다. 키 교환 방식에 따라 다릅니다.

공격 방식	가능 여부	조건
능동적 중간자 공격 (트래픽 경유)	가능	네트워크 위치 확보
수동적 감청 (캡처 후 복호화)	조건부	RSA 키 교환일 때만. TLS 1.3이나 ECDHE 사용 시 불가

"서버 위장을 탐지할 수 없고, 그 결과 세션 내용 열람과 계정 탈취가 가능하다" 정도가 방어 가능한 표현입니다.

---

🏢 "내부 개발자만 씁니다"는 답변에 대한 검토

답변	검토 의견
내부 개발자만 사용한다	사용 주체가 아니라 접근 통제의 문제입니다. 방화벽 ACL이나 IP 제한이 없다면 "관행상 개발자만 쓴다"일 뿐, 내부망에 도달 가능한 모든 단말이 접근할 수 있습니다
내부망이라 안전하다	계정 탈취나 랜섬웨어로 내부에 발판이 생긴 뒤의 횡적 이동 단계에서, 로그 시스템은 우선 표적이 됩니다
의도적으로 공인 인증서를 안 쓴다	공인 인증서가 아니어도 무방합니다. 다만 개인키가 공개된 인증서를 쓰는 것은 별개 사안이고, 의도적 선택으로 정당화되지 않습니다
개발용이라 영향이 작다	대상이 로그 모니터링 시스템입니다. 침해사고 발생 시 유일한 증적이고, 접속기록·계정정보가 집중되는 곳입니다

특히 ③ 경로가 성립하면 피해 성격이 달라집니다. 단순 정보 노출이 아니라 로그 무결성 훼손입니다. 사고가 나도 원인 규명이 불가능해지므로, 그 시스템의 존재 목적 자체가 무력화됩니다.

컴플라이언스 관점

기준	관련 요구사항	저촉 지점
PCI DSS 4.0	2.2.7 비콘솔 관리 접근의 강력한 암호화	신뢰할 수 없는 인증서로 암호화의 실효성 상실
PCI DSS 4.0	10.3.2 감사로그 변조 방지	관리자 개인키 공개로 로그 변조 가능
전자금융기반시설 취약점 분석·평가	안전한 암호화 통신 적용 / 기본 설정값 변경	기본 인증서 유지는 기본 설정 미변경 항목에 해당

내부망이라는 이유만으로 예외 처리하기 어려운 항목들입니다.

---

📋 확인 방법

1. 실제 적용된 인증서의 발급자 확인

openssl s_client -connect <대상>:9200 </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates -ext subjectAltName

issuer에 Example Com Inc. Root CA가 나오면 확정입니다.

2. 설정 파일에서 데모 구성 여부 확인

grep -E "allow_unsafe_democertificates|admin_dn|pemcert_filepath|enforce_hostname_verification" \
  /etc/opensearch/opensearch.yml

데모 구성의 기본값은 이렇습니다.

설정	기본값	의미
plugins.security.allow_unsafe_democertificates	true	데모 인증서 사용을 허용하는 플래그. 설정명에 unsafe가 들어 있습니다
plugins.security.authcz.admin_dn	CN=kirk,...	관리자 권한 탈취 가능 여부를 가르는 항목
plugins.security.ssl.transport.enforce_hostname_verification	false	호스트명 검증 비활성
plugins.security.allow_default_init_securityindex	true	기본 보안 설정 자동 초기화 허용

첫 번째 항목이 소명 자료로 가장 유용합니다. 제조사가 스스로 unsafe라고 이름 붙인 구성을 운영 중이라는 객관적 근거가 됩니다.

3. 데모 인증서 파일 존재 여부

ls -l /etc/opensearch/{root-ca.pem,esnode.pem,esnode-key.pem,kirk.pem,kirk-key.pem}

체크리스트

확인 항목
인증서 발급자가 Example Com Inc. Root CA인가	☐
config 디렉터리에 esnode-key.pem·kirk-key.pem이 있는가	☐
admin_dn에 CN=kirk가 남아 있는가	☐
allow_unsafe_democertificates가 true인가	☐
9200·5601·9300 포트에 방화벽 ACL이 적용되어 있는가	☐
관리자 계정이 기본 비밀번호를 쓰고 있지는 않은가	☐
해당 클러스터에 개인정보·결제정보 관련 로그가 적재되는가	☐

⚠️ 2.11.1 이전 버전이라면 관리자 계정 기본 비밀번호도 함께 확인하세요. 2.12.0부터는 데모 구성 시 OPENSEARCH_INITIAL_ADMIN_PASSWORD로 비밀번호를 직접 지정하도록 바뀌었지만, 그 이전 버전에서 설치한 뒤 그대로 올라온 시스템이 남아 있을 수 있습니다.

---

🛠 조치 방향 — 사내 사설 CA가 없다면

여기서부터가 현실적인 문제입니다. 사내에 Private CA가 없고 공인 인증서만 있는 환경이라면, 한 번에 다 해결되지 않습니다. 구간을 나눠야 합니다.

구간	적용할 인증서	결과
Dashboards 5601 REST 9200	사내 도메인으로 발급받은 공인 인증서	51192·57582·45411 모두 해소 → 조치 완료
Transport 9300	자체 생성 인증서 + 방화벽으로 노드 간 통신만 허용	공개된 개인키 제거. 스캔 대상에서 빠지므로 51192도 뜨지 않음 → 위험 수용
공통	plugins.security.authcz.admin_dn에서 CN=kirk 제거 → 관리자 권한 탈취 경로 차단

Transport 구간에 공인 인증서를 넣을 수 없다는 점은 미리 알고 계셔야 합니다. 노드 간 상호 인증(mTLS) 구조라 클라이언트 인증서가 필요한데, 공인 CA는 그 용도로 발급해주지 않습니다. 담당 부서가 "공인 인증서를 넣었더니 노드 간 통신이 안 된다"고 회신해 오는 지점이 대개 여기입니다.

내부 호스트에도 공인 인증서를 발급받을 수 있다는 점은 의외로 잘 알려져 있지 않습니다. 사내 보유 도메인의 하위 호스트명을 쓰고 DNS 검증 방식으로 발급받으면, 그 이름이 사설 IP를 가리켜도 발급 자체는 문제없습니다.

---

🚫 이런 조치는 하지 마세요

① 스캐너 신뢰 CA 목록에 넣어서 탐지만 없애기

스캐너에 사내 CA를 신뢰 CA로 등록하는 기능은 실제로 제공됩니다. 다만 정식으로 운영되는 사내 PKI가 있을 때 의미가 있는 것이고, 이번처럼 임시로 만든 CA에 적용하면 사실상 탐지 회피입니다. 나중에 외부 평가에서 "스캐너 설정으로 지적을 없앴다"로 해석될 여지를 남기게 됩니다.

② 대외 서비스용 와일드카드 인증서를 그대로 복사해 쓰기

비용이 안 드니 가장 먼저 떠오르는 방법인데, 권하지 않습니다.

항목	내용
개인키 사본 증가	대외 서비스 인증서의 개인키가 내부 로그 서버에도 복사됩니다
영향 범위 확대	해당 서버가 침해되면 대외 서비스 인증서까지 폐기·재발급해야 합니다
별건 지적 소지	인증서 개인키 관리 범위가 넓어지는 것 자체가 다음 점검의 지적 사유가 됩니다

로그 서버는 관리 우선순위가 상대적으로 낮게 잡히는 경우가 많습니다. 대외 인증서의 키를 둘 자리는 아닙니다.

③ 인증서만 바꾸고 접근 통제는 그대로 두기

이 건에서 가장 놓치기 쉬운 부분입니다. 인증서를 교체해도 "내부망 전 단말에서 로그 시스템에 접근 가능"한 상태는 그대로 남습니다. 인증서 발급에 몇 주가 걸리는 동안 노출 상태도 유지됩니다.

회신 요청에 접근 통제 확인을 한 줄이라도 같이 넣으세요. 이걸 빼면 다음 분기에 같은 논의를 처음부터 다시 하게 됩니다.

---

💬 자주 나오는 질문

Q. 자체 생성 인증서로 바꿔도 51192는 계속 뜨지 않나요?

네, 계속 뜹니다. 다만 같은 취약점이 아닙니다. 57582와 45411은 해소되어 세 건이 한 건으로 줄고, 무엇보다 "공개된 개인키" 상태가 "사내에서 관리하는 개인키" 상태로 바뀝니다. 위험 등급 자체가 달라지므로, 조치 계획서에 단계 조치로 기재할 수 있습니다.

Q. 그냥 내부 위험 수용으로 처리하면 안 되나요?

내부 정기 스캔 결과라면 사내 절차에 따른 위험 수용이 가능합니다. 다만 위험 수용의 대상을 정확히 좁혀야 합니다. "사설 인증서 사용"은 수용할 수 있어도, "개인키가 공개된 인증서 사용"은 수용 사유를 쓰기 어렵습니다. PCI DSS ASV 스캔 범위에 포함되는 시스템이라면 Medium 이상은 그대로 두면 Fail입니다.

Q. 발급자만 Example Com Inc.이고 나머지는 직접 만든 것일 수도 있지 않나요?

가능성은 낮지만 확인은 하는 편이 좋습니다. config 디렉터리의 파일명이 esnode.pem·kirk.pem 그대로인지, admin_dn이 CN=kirk인지를 보면 됩니다. 셋 다 일치하면 데모 구성입니다.

Q. 조치 완료 판정은 어떻게 하나요?

항목	판정	근거
데모 인증서 제거	조치 완료	공개된 개인키 제거
CN=kirk 제거	조치 완료	관리자 권한 탈취 경로 차단
웹 접속 구간 51192	조치 완료	신뢰 가능한 인증서 적용
Transport 구간 51192	위험 수용	구조상 사설 인증서 필수 + 접근 통제로 보완

---

📮 통보 문안 예시

[점검 결과]
해당 서버의 OpenSearch에 설치 시 기본 제공되는 데모 인증서(발급자: Example Com Inc. Root CA)가 
그대로 적용되어 있음을 확인하였습니다.

해당 데모 인증서는 인증서 파일과 함께 개인키 파일(esnode-key.pem,kirk-key.pem)이 
OpenSearch 배포 패키지에 동일하게 포함되어 설치 시 config 디렉터리에 생성됩니다. 
모든 설치 환경이 동일한 개인키를사용하므로, 개인키가 사실상 공개된 상태입니다. 
따라서 임의의 제3자가 동일한 개인키로 해당 서버를 위장할 수 있으며, 
이용자는 인증서를 통해접속 중인 서버의 진위를 식별할 수 없습니다.

또한 데모 구성의 기본 관리자 인증서(CN=kirk)가 관리자 DN(plugins.security.authcz.admin_dn)에 
등록된 상태라면, 공개된 개인키만으로 클러스터 관리자 권한 획득이 가능하여 로그 데이터의
열람·삭제·변조로 이어질 수 있습니다. OpenSearch 공식 문서에서도 
데모 인증서는 시험 용도로만 제공되며 운영 환경 사용을 금지하고 있습니다.

[조치 요청]
1. 사내 도메인으로 발급받은 공인 인증서 적용
2. plugins.security.authcz.admin_dn 에서 CN=kirk 제거

[확인 요청]
"내부 개발자만 사용" 관련하여 실제 접근 통제 수단(방화벽 ACL,IP 제한 등) 
적용 여부를 회신 부탁드립니다. 미적용 시 인증서 조치와 별개로 접근 통제 적용이 필요합니다.

---

🎉 정리

1. 발급자부터 확인한다. Example Com Inc. Root CA면 데모 인증서다.
2. 인증서가 아니라 개인키가 문제다. 인증서는 공개키만 담지만, 데모 구성은 개인키까지 배포 패키지에 함께 넣어 배포한다.
3. "공인 인증서를 안 썼다"로 접근하지 않는다. 내부 도메인은 원래 사설 인증서를 쓸 수 있다. 쟁점은 개인키 공개다.
4. 루트 CA 개인키는 배포되지 않는다. 임의 인증서 발급은 불가하므로, admin_dn에서 CN=kirk 제거는 유효한 즉시 조치다.
5. Transport 구간은 공인 인증서로 대체되지 않는다. 자체 생성 인증서 + 방화벽 차단이 현실적인 답이다.
6. 대외 서비스용 인증서를 복사해 쓰지 않는다. 개인키 관리 범위만 넓어진다.
7. 접근 통제 확인을 반드시 같이 요청한다. 인증서를 바꿔도 접근 범위는 그대로다.

"내부용이라 괜찮다"는 답변이 항상 틀린 건 아닙니다. 다만 그 답변이 맞으려면 내부용으로만 쓰이도록 막혀 있어야 합니다. 이 건은 결국 인증서 이야기로 시작해서 접근 통제 이야기로 끝나는 항목입니다.

---

🔗 참고 자료

• OpenSearch — Security configuration — 데모 인증서를 직접 발급한 인증서로 교체하는 절차
• OpenSearch — Generating self-signed certificates — 자체 CA·노드·클라이언트 인증서 생성 방법
• opensearch-project/security — DEVELOPER_GUIDE.md — 데모 인증서 생성 명령과 고정 DN, 루트 키 삭제 절차
• opensearch-project/security — Issue #1465 — 기동 시 출력되는 데모 인증서 파일 권한 경고 로그 실례
• OpenSearch Blog — The end of the default admin password — 2.12.0의 관리자 기본 비밀번호 폐지