Home
보안
이 절에서는 실행 제어 목록, ID 및 TLS를 포함한 보안 기능에 대해 설명합니다.
TLS 보안
TLS(Transport Layer Security)는 TCP/IP에서 작동하는 Domino® 서버 태스크의 통신 개인정보 보호 및 인증을 제공하는 보안 프로토콜입니다.
인증서 관리자 없이 TLS 인증서 관리
인증서 관리자(CertMgr) 및 인증서 저장소(certstore.nsf) 데이터베이스로 인증서를 관리하지 않는 경우 이 섹션에서 설명하는 대로 인증서를 수동으로 생성하고 관리합니다.

보안
이 절에서는 실행 제어 목록, ID 및 TLS를 포함한 보안 기능에 대해 설명합니다.
- Domino 보안 개요
  조직의 보안 설정은 아주 중요한 태스크입니다. 조직의 IT 자원 및 자산 보호를 위해 보안 하부 구조가 반드시 필요하며 관리자는 서버 또는 사용자를 설정하기 전에 조직의 보안 요구사항에 대해 신중히 고려해야 합니다. 사전 보안 계획으로 절충안을 채택한 보안상의 위험을 최소화할 수 있습니다.
- Notes® 사용자, 인터넷 사용자 및 Domino® 서버에 대한 서버 액세스
  다른 서버에 대한 사용자 및 서버의 액세스를 제어하기 위해, Domino®는 유효성 검증 및 인증 규칙과 서버 문서의 보안 탭에서 지정하는 설정을 사용합니다. 서버가 Notes® 사용자, 인터넷 사용자 또는 서버의 유효성을 검증하고 인증하며 서버 문서의 설정이 액세스를 허용하는 경우, 사용자 또는 서버는 서버에 액세스할 수 있습니다.
- 데이터베이스 ACL
  모든 .NSF 데이터베이스에는 해당 데이터베이스에 대한 사용자와 서버의 액세스 레벨을 지정하는 ACL이 있습니다. 사용자와 서버에 대한 액세스 레벨 이름이 동일하더라도 사용자에게 할당된 레벨은 사용자가 데이터베이스에서 수행할 수 있는 태스크를 결정하는 반면, 서버에 할당된 레벨은 데이터베이스 내에서 서버가 어떤 정보를 복제할 수 있는지 결정합니다. 관리자 권한을 가지는 사용자만 ACL을 작성하거나 수정할 수 있습니다.
- Domino® 서버 및 Notes® 사용자 ID
  Domino® 는 ID 파일을 사용하여 사용자를 식별하고 서버에 대한 액세스를 제어합니다. 모든 Domino 서버, Notes® 인증자 및 Notes 사용자는 ID를 갖고 있어야 합니다.
- 실행 제어 목록(ECL)
  ECL(실행 제어 목록)을 사용하여 워크스테이션 데이터 보안을 설정합니다. ECL은 출처를 알 수 없거나 의심되는 사용 중인 내용으로부터 사용자 워크스테이션을 보호하며, 워크스테이션에서 실행되는 내용 수행을 제한하도록 설정될 수 있습니다.
- Domino® 서버 기반 CA(Server-based certification authority)
  CA 프로세스 서버 태스크를 사용하는 Domino® 인증자를 설정하여 인증서 요청을 관리하고 처리할 수 있습니다. 인증 기관 프로세스는 인증서를 발행하는 데 사용되는 Domino 서버에서 프로세스로 실행됩니다. Notes® 또는 인터넷 인증자를 설정할 때 CA 프로세스 활동을 이용하기 위해 서버의 CA 프로세스에 링크합니다. CA 프로세스는 한 번만 서버에서 실행되지만 여러 인증자에 연결할 수 있습니다.
- TLS 보안
  TLS(Transport Layer Security)는 TCP/IP에서 작동하는 Domino® 서버 태스크의 통신 개인정보 보호 및 인증을 제공하는 보안 프로토콜입니다.
  - 인증서 관리자를 통해 TLS 인증서 관리
    HCL Domino® 12에서는 인증서 저장소(certstore.nsf)라는 새 데이터베이스와 함께 작동하여 Domino 환경에서 TLS 인증서를 관리하는 인증서 관리자(CertMgr)라는 새로운 서버 태스크를 도입했습니다.
  - TLS 포트 구성
    항상 TLS 프로토콜을 통해 통신 채널이 암호화되고 무결성이 확인되며 서버 신원이 인증됩니다. 다양한 양식의 클라이언트 신원 인증을 요구하도록 TLS 서버를 선택적으로 설정할 수 있습니다.
  - 서버에 대한 TLS 연결 요구
    클라이언트가 보안 연결을 사용하여 서버의 데이터베이스에 액세스해야 할 때, TLS 연결을 요구하십시오. TCP/IP 포트를 통해 TLS 포트로 들어오는 연결 요청 방향을 리디렉션하여 연결을 요구합니다. TLS 연결을 요구하지 않을 경우, 클라이언트는 TLS 또는 TCP/IP를 사용하여 서버에 대한 액세스 여부를 결정할 수 있습니다.
  - 서버-서버 TLS에 대한 인터넷 교차 인증서 작성
    하나의 서버가 신뢰를 얻기 위해 다른 서버로부터 인터넷 교차 인증서를 얻을 수 있습니다. 예로는 어떤 서버가 다른 서버의 디렉토리 보조자에 액세스해야 할 경우를 들 수 있습니다.
  - TLS 클라이언트에 대한 데이터베이스 액세스 설정
    Domino® 서버에 TLS를 설정한 후, 서버에 있는 데이터베이스에 대한 클라이언트 액세스 권한을 부여해야 합니다.
  - TLS 암호 제한 수정
    TLS는 공용, 개인 및 협상된 세션 키를 사용합니다. 모든 TLS 인증서 세트에는 한 쌍의 키(공개 키와 개인 키)와 인증서 소유자가 네트워크에서 자신의 신분을 확인한 후 S/MIME을 사용하여 메시지를 암호화하고 서명할 수 있도록 지원하는 X.509 인증서가 들어 있습니다. 인증서는 키 쌍의 공개 키 쪽만 포함합니다. 개인 키는 Notes® 클라이언트에서는 ID 파일에 보관되고 TLS 서버에서는 키 링 파일 또는 cerstore.nsf 데이터베이스에 보관됩니다. Domino 12부터 Domino는 RSA 키와 ECDSA 키를 모두 지원합니다. 자세한 정보는 wn_ECDSA_cryptography.html의 내용을 참조하십시오.
  - 2차 Domino® 및 LDAP 디렉토리에 있는 웹 TLS 클라이언트 인증
    웹 클라이언트가 서버에서 인증할 때, 기본적으로 서버는 클라이언트 인증서가 사용자 문서에 존재하는지 알기 위해 1차 HCLDomino® 디렉토리를 확인합니다. 사용자 조직에서 2차 Domino 디렉토리 및/또는 LDAP 디렉토리를 사용하여 클라이언트 인증서를 확인할 경우, 추가 디렉토리를 검사하도록 Domino를 설정할 수 있습니다. 이렇게 하려면 디렉토리 보조자 데이터베이스에서 2차 Domino 및 LDAP 디렉토리를 신뢰된 도메인으로 설정하십시오.
  - TLS 세션 복구
    TLS 세션을 복구하면 TLS 세션 키 협상 과정에서 처리 시간이 가장 오래 걸리는 과정을 통과하기 위해 이전의 성공적인 TLS 세션 협상의 정보를 다시 불러와서 TLS를 사용할 때 성능이 크게 향상됩니다. HTTP가 TLS 세션 복구 시 가장 큰 이익을 얻는 프로토콜이지만 다른 인터넷 프로토콜도 이익을 얻습니다.
  - 인증서 관리자 없이 TLS 인증서 관리
    인증서 관리자(CertMgr) 및 인증서 저장소(certstore.nsf) 데이터베이스로 인증서를 관리하지 않는 경우 이 섹션에서 설명하는 대로 인증서를 수동으로 생성하고 관리합니다.
    - 자체 서명 또는 써드파티 인증서로 키링 파일 생성
      서버에 TLS를 설정하려면, 인터넷 CA의 서버 인증서가 필요합니다.
    - TLS 서버 인증서 보기
      TLS 서버 인증에 대한 정보를 볼 수 있습니다.
    - 서버 키 링 파일의 비밀번호 변경
      서버 키 링 파일의 비밀번호를 변경할 수 있습니다. 비밀번호는 12개 이상의 영숫자여야 합니다.
    - CA 인증서를 신뢰된 루트로 표시 또는 표시하지 않기
      CA에서 서명한 인증서를 사용하는 서버 및 클라이언트와 더 이상 통신하지 않을 때, 서버 인증서에서 신뢰된 루트인 CA 인증서를 삭제합니다.
    - 인증서에 대한 요청 보기
      서버 관리자는 요청을 추적하기 위해 CA에 발송한 인증서 요청에 대한 정보를 볼 수 있습니다. 요청 문서는 인증서를 제출하는 데 사용된 방법, 요청 날짜 및 시간, 인증서의 키 링 파일, 인증서에 대한 정보와, 사용된 경우 서버 관리자가 요청을 발송한 이메일 주소를 추적합니다.
    - 만료된 인증서 갱신
      인증서가 만료되면, 서버 및 클라이언트와 통신하는데 더 이상 사용할 수 없습니다. 써드파티 CA에서 서버 인증서를 확보한 경우 써드파티 CA의 웹 사이트에 요청을 제출하여 갱신할 수 있는데, 사용자 이름, 비밀번호 및 질문 구문을 포함하여 요청할 때가 많습니다. 서버 인증서 갱신이 가능한 경우, 이 정보가 수신되어 갱신하라는 메시지가 나타납니다. 서버 인증서를 갱신할 수 없는 경우, 새 인증서에 대한 요청을 제출해야 합니다.
    - TLS 인증을 검사할 자체 인증된 인증서 작성
      조직에서 인증서 과정을 검사할 자체 인증된 인증서를 작성할 수 있습니다. 이 인증서는 CA에서 인증하지 않으므로, 검사 목적으로만 사용합니다.
- 클라이언트에 대한 TLS 및 S/MIME
  클라이언트는 Domino® 인증 기관 애플리케이션 또는 써드파티 인증 기관을 사용하여 보안 TLS 및 S/MIME 통신용 인증서를 가져올 수 있습니다.
- 암호화
  암호화는 인증되지 않은 액세스로부터 데이터를 보호합니다.
- 인터넷/인트라넷 클라이언트에 대한 이름과 비밀번호 인증 확인
  이름과 비밀번호 인증 확인(또는 기본 비밀번호 인증 확인)은 사용자에게 이름과 비밀번호를 묻기 위한 기본 질문/응답 프로토콜을 사용한 후, Domino® 디렉토리의 사용자 문서에 저장된 비밀번호의 보안 해시와 비교하여 비밀번호의 정확성을 확인합니다.
- TOTP(시간 기반 일회성 비밀번호) 인증
  사용자가 Domino 웹 서버에 로그인할 때 사용자 이름 및 비밀번호에 더해 시간 기반 일회성 비밀번호를 제공하도록 요구할 수 있습니다.
- 다중 서버 세션 기반 인증(single sign-on)
  다중 서버 세션 기반 인증(SSO라고도 함)을 통해 웹 사용자는 Domino® 또는 WebSphere® 서버에 한 번 로그인한 후 다시 로그인하지 않고도 SSO에 대해 사용으로 설정된 동일한 DNS 도메인 내의 다른 Domino 또는 WebSphere 서버에 액세스할 수 있습니다.
- SAML(Security Assertion Markup Language)을 사용하여 연합 ID 인증 구성
  연합 ID는 싱글 사인온을 실현하여 사용자에게 편의를 제공하고 관리 비용을 줄이는 데 도움이 되는 방법입니다. Domino® 및 Notes®에서 사용자 인증을 위한 연합 ID는 OASIS의 SAML(Security Assertion Markup Language) 표준을 사용합니다.
- OIDC(OpenID Connect)를 사용하여 연합 ID 인증 구성
  연합 ID는 싱글 사인온을 실현하여 사용자에게 편의를 제공하고 관리 비용을 줄이는 데 도움이 되는 방법입니다. 클라이언트 애플리케이션에서 사용자를 인증하는 한 가지 방법으로 OIDC(OpenID Connect) 제공자를 사용합니다.
- 신임 정보 저장소를 사용하여 신임 정보 저장
  Domino® 서버에서는 신임 정보 저장소 애플리케이션을 보안 아티팩트 저장소로 사용할 수 있습니다. 보안 아티팩트의 예로는 인증 신임 정보 및 보안 키가 있습니다.
- Notes 및 Domino의 지원되는 키 크기 히스토리
  Notes® 및 Domino®의 이전 릴리스에서 현재 릴리스까지 지원되는 RSA 키 크기를 이해하십시오.

인증서 관리자 없이 TLS 인증서 관리

인증서 관리자(CertMgr) 및 인증서 저장소(certstore.nsf) 데이터베이스로 인증서를 관리하지 않는 경우 이 섹션에서 설명하는 대로 인증서를 수동으로 생성하고 관리합니다.

이 태스크 정보

Domino 12부터 CertMgr 및 certstore.nsf를 사용하는 것이 TLS 인증서를 작성하고 관리하는 권장되는 방법입니다.