이 절에서는 실행 제어 목록, ID 및 TLS를 포함한 보안 기능에 대해 설명합니다.
TLS(Transport Layer Security)는 TCP/IP에서 작동하는 Domino® 서버 태스크의 통신 개인정보 보호 및 인증을 제공하는 보안 프로토콜입니다.
HCL Domino® 12에서는 인증서 저장소(certstore.nsf)라는 새 데이터베이스와 함께 작동하여 Domino 환경에서 TLS 인증서를 관리하는 인증서 관리자(CertMgr)라는 새로운 서버 태스크를 도입했습니다.
TLS 호스트 키 롤오버(일반적) 또는 ACME 계정 키 롤오버를 요청할 수 있습니다.
조직의 보안 설정은 아주 중요한 태스크입니다. 조직의 IT 자원 및 자산 보호를 위해 보안 하부 구조가 반드시 필요하며 관리자는 서버 또는 사용자를 설정하기 전에 조직의 보안 요구사항에 대해 신중히 고려해야 합니다. 사전 보안 계획으로 절충안을 채택한 보안상의 위험을 최소화할 수 있습니다.
다른 서버에 대한 사용자 및 서버의 액세스를 제어하기 위해, Domino®는 유효성 검증 및 인증 규칙과 서버 문서의 보안 탭에서 지정하는 설정을 사용합니다. 서버가 Notes® 사용자, 인터넷 사용자 또는 서버의 유효성을 검증하고 인증하며 서버 문서의 설정이 액세스를 허용하는 경우, 사용자 또는 서버는 서버에 액세스할 수 있습니다.
모든 .NSF 데이터베이스에는 해당 데이터베이스에 대한 사용자와 서버의 액세스 레벨을 지정하는 ACL이 있습니다. 사용자와 서버에 대한 액세스 레벨 이름이 동일하더라도 사용자에게 할당된 레벨은 사용자가 데이터베이스에서 수행할 수 있는 태스크를 결정하는 반면, 서버에 할당된 레벨은 데이터베이스 내에서 서버가 어떤 정보를 복제할 수 있는지 결정합니다. 관리자 권한을 가지는 사용자만 ACL을 작성하거나 수정할 수 있습니다.
Domino® 는 ID 파일을 사용하여 사용자를 식별하고 서버에 대한 액세스를 제어합니다. 모든 Domino 서버, Notes® 인증자 및 Notes 사용자는 ID를 갖고 있어야 합니다.
ECL(실행 제어 목록)을 사용하여 워크스테이션 데이터 보안을 설정합니다. ECL은 출처를 알 수 없거나 의심되는 사용 중인 내용으로부터 사용자 워크스테이션을 보호하며, 워크스테이션에서 실행되는 내용 수행을 제한하도록 설정될 수 있습니다.
CA 프로세스 서버 태스크를 사용하는 Domino® 인증자를 설정하여 인증서 요청을 관리하고 처리할 수 있습니다. 인증 기관 프로세스는 인증서를 발행하는 데 사용되는 Domino 서버에서 프로세스로 실행됩니다. Notes® 또는 인터넷 인증자를 설정할 때 CA 프로세스 활동을 이용하기 위해 서버의 CA 프로세스에 링크합니다. CA 프로세스는 한 번만 서버에서 실행되지만 여러 인증자에 연결할 수 있습니다.
CertMgr을(를) ServerTasks notes.ini 설정에 추가하거나 프로그램 문서에서 실행하도록 예약하여 CertMgr을 자동으로 시작하도록 구성합니다. 처음 실행하면 인증서 저장소 데이터베이스(certstore.nsf)가 작성됩니다.
CertMgr
도메인의 웹 서버에서 certmgr을 실행하여 certstore.nsf의 복제본을 작성합니다.
인증서 관리에 사용할 기본 값을 설정하도록 글로벌 설정을 구성합니다.
CertMgr은 ACME 프로토콜을 사용하여 Let's Encrypt® CA(인증 기관)에서 널리 신뢰되는 무료 TLS 인증서를 자동으로 요청, 구성 및 갱신할 수 있는 기능을 제공함으로써 Domino 웹 서버 조작을 단순화하고 보호합니다.
HCL Domino® 12 이상에서 Domino 서버에서 써드파티 인증 기관(C)의 인터넷 인증서를 구성하는 프로세스가 더 간단해졌습니다.
아직 TLS 신임 정보 문서에 추가되지 않은 디스크에 TLS 신임 정보가 있는 경우, CertMgr에서 사용할 수 있도록 certstore.nsf 데이터베이스를 사용하여 가져올 수 있습니다.
TLS 신임 정보 문서의 신임 정보를 파일로 내보낼 수 있습니다.
신뢰할 수 있는 루트 인증서를 사용하면 웹 서버에서 연결 중인 클라이언트의 신뢰된 루트 인증서를 수락할 수 있습니다. 신뢰할 수 있는 루트 인증서는 CA에서 제공하는 부분 인증서 체인을 자동으로 완료하는 데에도 유용합니다.
마이크로 CA에서 웹 서버 TLS 인증서를 작성할 수 있습니다.
CertMgr은 Let's Encrypt® CA 또는 써드파티 CA에서 생성되는 TLS 1.2 호스트 키(키링 파일) 및 ACME 계정에 대해 NIST P-256 및 NIST P-384 곡선을 사용하여 ECDSA(Elliptic Curve Digital Signature Algorithm)를 지원합니다.
TLS 호스트 키 쌍이 손상되거나 키 유형 또는 키 크기를 변경하려면 키 롤오버를 요청합니다.
ACME 계정 키가 손상된 경우 키 롤오버를 요청합니다.
키 롤오버를 요청하는 경우 키 롤오버 요청 필드에서 다음 옵션 중 하나를 선택합니다.
더 이상 유효하지 않은 인증서에 대한 아카이브 문서는 certstore.nsf의 TLS 신임 정보 > 아카이브 보기에 저장됩니다.
load certmgr 명령은 다음 매개변수와 함께 실행될 수 있습니다.
load certmgr
사용할 수 있는 CertMgr tell 명령은 다음과 같습니다.
CertMgr에는 다음 notes.ini 설정이 포함되어 있습니다. 일부 설정은 명령행 매개변수에 해당하며 관련 내용이 명시되어 있습니다.
CertMgr 태스크에서는 가져오는 시점과 이후 30분마다 가져온 키와 인증서의 상태를 확인합니다.
CertMgr은 TLS 신임 정보 문서에 지정된 대상 URL 엔드포인트에서 TLS 인증서 검증을 지원합니다. 이 검증에서는 인증 만료를 확인하고 인증서가 만료된 경우 관리자에게 알립니다.
Domino 디렉토리 및 인증서 저장소의 인터넷 CA 루트 인증서가 추가 필드를 포함하도록 업데이트되었습니다.
CertMgr 디버그 로깅을 사용하도록 설정하는 데 사용되는 load certmgr -d 명령에는 단일 위치에서 문제 해결 정보를 제공하기 위한 일반 메시지 로깅도 포함됩니다. 이 로깅은 Let's Encrypt 인증 기관 및 써드파티 CA의 인증서와 관련이 있습니다.
load certmgr -d
항상 TLS 프로토콜을 통해 통신 채널이 암호화되고 무결성이 확인되며 서버 신원이 인증됩니다. 다양한 양식의 클라이언트 신원 인증을 요구하도록 TLS 서버를 선택적으로 설정할 수 있습니다.
클라이언트가 보안 연결을 사용하여 서버의 데이터베이스에 액세스해야 할 때, TLS 연결을 요구하십시오. TCP/IP 포트를 통해 TLS 포트로 들어오는 연결 요청 방향을 리디렉션하여 연결을 요구합니다. TLS 연결을 요구하지 않을 경우, 클라이언트는 TLS 또는 TCP/IP를 사용하여 서버에 대한 액세스 여부를 결정할 수 있습니다.
하나의 서버가 신뢰를 얻기 위해 다른 서버로부터 인터넷 교차 인증서를 얻을 수 있습니다. 예로는 어떤 서버가 다른 서버의 디렉토리 보조자에 액세스해야 할 경우를 들 수 있습니다.
Domino® 서버에 TLS를 설정한 후, 서버에 있는 데이터베이스에 대한 클라이언트 액세스 권한을 부여해야 합니다.
TLS는 공용, 개인 및 협상된 세션 키를 사용합니다. 모든 TLS 인증서 세트에는 한 쌍의 키(공개 키와 개인 키)와 인증서 소유자가 네트워크에서 자신의 신분을 확인한 후 S/MIME을 사용하여 메시지를 암호화하고 서명할 수 있도록 지원하는 X.509 인증서가 들어 있습니다. 인증서는 키 쌍의 공개 키 쪽만 포함합니다. 개인 키는 Notes® 클라이언트에서는 ID 파일에 보관되고 TLS 서버에서는 키 링 파일 또는 cerstore.nsf 데이터베이스에 보관됩니다. Domino 12부터 Domino는 RSA 키와 ECDSA 키를 모두 지원합니다. 자세한 정보는 wn_ECDSA_cryptography.html의 내용을 참조하십시오.
웹 클라이언트가 서버에서 인증할 때, 기본적으로 서버는 클라이언트 인증서가 사용자 문서에 존재하는지 알기 위해 1차 HCLDomino® 디렉토리를 확인합니다. 사용자 조직에서 2차 Domino 디렉토리 및/또는 LDAP 디렉토리를 사용하여 클라이언트 인증서를 확인할 경우, 추가 디렉토리를 검사하도록 Domino를 설정할 수 있습니다. 이렇게 하려면 디렉토리 보조자 데이터베이스에서 2차 Domino 및 LDAP 디렉토리를 신뢰된 도메인으로 설정하십시오.
TLS 세션을 복구하면 TLS 세션 키 협상 과정에서 처리 시간이 가장 오래 걸리는 과정을 통과하기 위해 이전의 성공적인 TLS 세션 협상의 정보를 다시 불러와서 TLS를 사용할 때 성능이 크게 향상됩니다. HTTP가 TLS 세션 복구 시 가장 큰 이익을 얻는 프로토콜이지만 다른 인터넷 프로토콜도 이익을 얻습니다.
인증서 관리자(CertMgr) 및 인증서 저장소(certstore.nsf) 데이터베이스로 인증서를 관리하지 않는 경우 이 섹션에서 설명하는 대로 인증서를 수동으로 생성하고 관리합니다.
클라이언트는 Domino® 인증 기관 애플리케이션 또는 써드파티 인증 기관을 사용하여 보안 TLS 및 S/MIME 통신용 인증서를 가져올 수 있습니다.
암호화는 인증되지 않은 액세스로부터 데이터를 보호합니다.
이름과 비밀번호 인증 확인(또는 기본 비밀번호 인증 확인)은 사용자에게 이름과 비밀번호를 묻기 위한 기본 질문/응답 프로토콜을 사용한 후, Domino® 디렉토리의 사용자 문서에 저장된 비밀번호의 보안 해시와 비교하여 비밀번호의 정확성을 확인합니다.
사용자가 Domino 웹 서버에 로그인할 때 사용자 이름 및 비밀번호에 더해 시간 기반 일회성 비밀번호를 제공하도록 요구할 수 있습니다.
다중 서버 세션 기반 인증(SSO라고도 함)을 통해 웹 사용자는 Domino® 또는 WebSphere® 서버에 한 번 로그인한 후 다시 로그인하지 않고도 SSO에 대해 사용으로 설정된 동일한 DNS 도메인 내의 다른 Domino 또는 WebSphere 서버에 액세스할 수 있습니다.
연합 ID는 싱글 사인온을 실현하여 사용자에게 편의를 제공하고 관리 비용을 줄이는 데 도움이 되는 방법입니다. Domino® 및 Notes®에서 사용자 인증을 위한 연합 ID는 OASIS의 SAML(Security Assertion Markup Language) 표준을 사용합니다.
연합 ID는 싱글 사인온을 실현하여 사용자에게 편의를 제공하고 관리 비용을 줄이는 데 도움이 되는 방법입니다. 클라이언트 애플리케이션에서 사용자를 인증하는 한 가지 방법으로 OIDC(OpenID Connect) 제공자를 사용합니다.
Domino® 서버에서는 신임 정보 저장소 애플리케이션을 보안 아티팩트 저장소로 사용할 수 있습니다. 보안 아티팩트의 예로는 인증 신임 정보 및 보안 키가 있습니다.
Notes® 및 Domino®의 이전 릴리스에서 현재 릴리스까지 지원되는 RSA 키 크기를 이해하십시오.