CA 계획하기
대상 : 아키텍트, 네트워크 관리자, 프로덕션 패브릭 네트워크를 설정하고 전송 계층 보안(TLS), 공개키 인프라스트럭처(PKI), 멤버십 서비스 공급자(MSPs)에 익숙한 사용자
이 배포 지침은 프로덕션 네트워크를 위한 CA 배포 방법을 가이드한다. 교육 또는 테스트 목적으로 빠르게 네트워크를 시작하고 싶을 경우 패브릭 테스트 네트워크를 확인하자. Fabric CA server는 하이퍼레저 패브릭에 대해 선호되고 테스트된 인증 기관으로 남아 있지만, non-Fabric CA에서 온 인증서를 패브릭 네트워크를 위해 대신 사용할 수 있다; 하지만 이 배포 가이드의 범위는 패브릭 CA를 사용하는 것에 집중한다. 이것은 CA 구성을 위해 고려하고 가장 좋은 방식을 제공해야 하는 가장 중요한 구성 파라미터에 집중한다.
당신은 어쩌면 Fabric CA 유저 가이드나 운영 가이드에 이미 친숙할 수 있다. 이 주제는 CA 배포 이전에 결정을 내리도록 하고 그 결정에 기반해 CA 파라미터를 구성하는 방법에 대한 가이드를 제공한다. 결정을 내리기 위해 이 주제들에 대한 참조가 여전히 필요할 수 있다.
Fabric CA는 블록체인 네트워크에서 아래 기능을 수행한다는 것을 다시 떠올려 보자:
- 신원을 기재하거나 유저 레지스트리로서 Lightweight Directory Access Protocol (LDAP)를 연결한다.
- 등록 인증서(ECerts)를 발행한다. 등록은 단일 인증서와 신원을 형성하는 개인 키로 구성된 인증서 키 페이를 Fabric CA가 발행하는 과정이다. 비밀 키 와 공개 키는 Fabric CA 클라이언트에 의해 로컬에 처음 생성되고, 공개키가 CA로 전송되어 인코딩된 인증서인 서명 인증서를 반환하게 한다.
- 인증서 리뉴얼 및 페지
이 기능들의 동작을 커스터마이징할 기회가 있다. 처음 CA가 시작될 때 CA는 fabric-ca-server-config.yaml file를 바라본다. 이 파일은 CA 구성 파라미터들을 가지고 있다. 만약 이 파일이 업다면 기본 파일이 생성된다. CA를 배포하기 전, 이 토픽은 이 파일의 파라미터들에 대해, 그리고 유즈케이스에 따라 CA를 커스터마이징하기위해 내려야 하는 결정에 대해 가이드를 제공한다.
네트워크에서 사용할 CA 토폴로지는 무엇인가?
네트워크 CA의 토폴로지는 얼마나 많은 조직들이 네트워크에 참여했는지와 어떻게 CA를 관리하기를 원하는지에 따라 다양해질 수 있다.
얼마나 많은 CA가 필요한가?
CA를 구성하기 전, 네트워크에 얼마나 많은 CA가 필요한지 이해해야 한다. 배포 프로세스 개요를 읽었다면 각 조직에 대해 두 CA를 배포하는 것을 추천한 걸 기억할 것이다. 하나는 조직 CA이고 하나는 TLS CA이다. TLS 통신은 조직 노드 간 안전한 통신을 위해 모든 프로덕션 네트워크에 필수적이다. 이 TLS 인증서들을 발행하는 것이 TLS CA이다. 조직 CA는 반면 조직과 노드의 신원을 생성할 때 사용된다. 또한, 분산 원장이 있기 때문에, 오더링 서비스는 피어들과 동일한 조직의 일부가 될 수 없다. 따라서 피어 조직과 오더러 서비스 조직에 대해 분리된 조직들과 CA들이 필요하다. 여러 조직이 오더링 서비스를 형성하는 노드를 가지고 있다면 각 오더링 노드는 자신이 소유하는 조직 CA를 가지고 있어야 한다. 이 모든 분산은 오더링 서비스와 채널의 분산 관리를 위해 중요하고, 네트워크를 붕괴시키기 위한 행위를 막는다.
왜 각각 분리된 TLS 서버가 추천되는가?
분리된 TLS 서버는 보안 통신만을 위해 독립적인 신뢰 체인을 제공한다. 대부분의 조직은 TLS 통신이 다른 Fabric TLS CA나 외부 인증 기관으로부터 독립적인 암호화 자료에 의해 보안되는 것을 선호한다.
패브릭이 제공하는 한 가지 옵션은 dual-headed CA를 구성하는 것이다. 커버 아래에 있는 단일 CA가 앞으로 조직 CA라고 불릴 조직의 신원 등록 CA와 TLS CA를 포함하는 것이다. 이들은 동일한 CA 노드와 포트에서 운영되지만 서로 다른 CA 이름으로 주소 지정이 가능하다. cafiles 파라미터는 이후 더 자세히 다루어질 것인데, 이것은 각 CA가 자신만의 구성을 가지지만 동일한 백엔드 데이터베이스를 공유하도록 할 때 유익하다. 따라서 이 옵션을 사용하면, 편리하게도, 조직 CA가 배포될 때 TLS CA가 자동적으로 배포된다.
기능적 측면에서 패브릭 조직 CA와 패브릭 TLS CA는 차이가 없음에도 주의를 기울일 가치가 있다. 그것들이 생성하는 인증서의 종류에서 차이가 있다.
언제 중간 CA가 필요해지는가?
중간 CA는 선택적이다. 추가적인 보안을 위해 조직은 중간 CA로 알려진 CA들의 체인을 배포할 수 잇다. 중간 CA는 자신의 루트 인증서를 부모 CA(루트 CA) 또는 다른 중간 인증기관(부모 CA가 되는)으로부터 발급받는다. 이는 체인의 어떤 CA로부터든 발행된 모든 인증서들을 위한 "신뢰 체인"을 형성한다. 따라서, 하나 이상의 중간 CA를 가지는 것은 신뢰 루트 보호에 도움이 된다. 루트 CA를 추적하는 이 기능은 여전히 보안을 제공하면서 CA의 기능을 확장할 뿐만 아니라(인증서를 사용하는 조직들이 자신 있게 중간 CA를 사용할 수 있도록 한다) 루트 CA 노출을 제한한다. 루트 CA가 훼손된다면(침해된다면) 전체 신뢰 체인이 위험에 놓이게 된다. 중간 CA가 훼쇤되는 경우에는 훨씬 작은 노출만이 생긴다. 핵심 이익은 중간 CA가 생성되고 구동된 후 루트 CA는 전원이 꺼져 취약성을 더욱 제한할 수 있다는 것이다.
중간 CA를 포함시키는 다른 이유는 여러 부서를 가진 매우 큰 조직을 가지고 있고 단일 CA가 모든 부서를 위한 인증서를 생성하기를 원치 않을 때이다. 중간 CA는 한 CA가 관리하는 인증서 범위를 더 작은 부서나 하위 그룹으로 만드는 메커니즘을 제공한다. 중간 CA는 필수가 아니지만 리스크를 완화시키고 인증서 관리 범위를 정한다. 이 패턴은 조직에 적은 수의 멤버만 있을 경우 유의미한 overheard를 발생시킨다. 여러 중간 CA를 배포하는 것의 대안으로서 affiliations(부서와 유사)를 사용해 CA를 구성할 수 있다. 이에 대해서는 나중에 더 자세히 이야기할 것이다.
또한 한 TLS CA를 사용해 전체 조직의 통신 보안을 위한 인증서를 발급하는 것이 허용되는 상황에서는 중간 CA가 동일한 TLS CA를 루트 CA로 사용하는것이 자신들만의 TLS CA를 가지는 것 보다 합리적이다.
어떤 순서로 CA가 배포되어야 하는가?
만약 dual-headed CA가 조직 CA와 TLS CA로 구성되지 않는다면, TLS CA가 독립적으로 배포되고,조직 CA보다 이전에 배포되어야 한다. 이것은 조직 CA를 위한 TLS 인증서를 생성하기 위함이다. TLS CA가 배포된 후, 조직 CA가 배포되고, 필요하다면 중간 CA들이 배포될 수 있다.
유저 레지스트리 결정
Fabric CA가 조직의 신원들을 컨트롤하기 때문에 CA를 구성하기 전에 유저 레지스트리를 결정해야 한다. 패브릭 CA 서버는 데이터베이스를 유저 레지스트리로 사용하도록 구성되거나 또는 Lightweight Directory Access Protocol (LDAP) 서버로부터 읽어올 수 있도록 구성될 수 있다. LDAP는 서버 데이터 저장 및 호출을 위한 산업 표준이고, 정보는 위계 트리로 표현된다. LDAP 프로토콜은 서버에서 데이터를 조회하기 위해 사용되고, 이 맥락에서 데이터는 유저나 그룹이므로, 서버가 유저 레포지토리가 된다. LDAP 서버가 유저 레포지토리가 될 때, 커넥션 및 구성 디테일을 준비해야 한다. LDAP 가 CA를 위해 구성된 후 이것은 등록이라고 알려진 프로세스로 유저에 대한 인증서가 생성되기 전에 LDAP 유저 레지스트리에 대해 신원을 인증한다. 추가적으로,LDAP 레지스트리에서 호출된 유저 속성은 스마트 컨트랙트에서 접근 컨트롤 결정을 내리는 데에 유용하다. LDAP에 대해 더 배우고 싶다면 LDAP 구성을 보자.
이 배포 가이드는 유저 레지스트리를 데이터베이스로 구성하는 프로세스를 설명한다.
구성에 대한 참고 사항
Fabric CA 서버와 클라이언트로 구성을 설정하는 세 가지 방법이 있다. 기본 설정을 오버라이딩하는 우선순위는 다음과 같다:
- Fabric CA server CLI 커맨드 사용
- 구성 파일 설정 오버라이딩을 위해 환경변수 사용
- 구성 파일 수정
이 순서는 코드 관점에서 Fabric CA server CLI 커맨드로 어떤 플래그이든 전달된다면 그것이 동일한 설정을 위한 (만약 존재한다면) 환경변수와 구성 파일의 기본 값을 오버라이딩 함을 의미한다. 마찬가지로 환경변수는 구성파일의 설정을 오버라이딩하기 위해 사용될 수 있다. 하지만 구성 설정을 위한 환경 변수 사용은 권장되지 않는다. 변경에 지속성이 없고 설정되어야 하는 환경변수가 설정되지 않았을 때 나중에 문제를 일으킬 수 있다. 구성 파일의 파라미터를 이해하는 것이 중요하고, 파일의 다른 파라미터 설정에 대한 디펜던시를 이해하는 것이 중요하다. 환경변수를 사용해 한 설정을 비밀스럽게 오버라이딩하는것은 다른 설정에 기능적인 영향을 미칠 수 있다. 결론적으로 서버를 시작하기 전에 구성 파일에서 설정을 수정해 가능한 설정들과 그것들이 동작하는 방식에 익숙해지는 것을 추천한다.
어떤 구성 설정들은 CA 데이터베이스에 저장됨을 주의해라. 이것은 CA가 시작된 후 구성 파일 수정이나 환경 변수 설정으로 해당 설정을 오버라이딩 할 수 없다는 뜻이다. 영향을 받는 파라미터들은 해당 지침을 통해 알려진다. 이 경우, 수정은 Fabric CA server CLI 커맨드를 통해 이루어져야 하고, 서버 재시작이 필요 없다는 추가 이득을 가지게 된다.
