프로덕션 CA 서버를 위한 체크리스트
프로덕션 패브릭 CA 서버 구축을 준비할 때, fabric-ca-server-config.yaml파일의 아래 필드 구성을 고려해야 한다. CA서버를 초기화할 때, 이 파일이 생성돼서 실제로 서버를 실행하기 전에 사용자 정의 구성을 할 수 있다.
이 체크리스트는 프로덕션 네트워크 설정의 핵심 구성 파라미터들이다. 물론 다른 파라미터나 정보를 이용하기 위해 fabric-ca-server-config.yaml 파일을 참고할 수 있다.
ca
ca:
# 이 CA의 이름
name:
# 키 파일(BCCSP에 개인키를 import할 때 필요하다)
keyfile:
# 인증서 파일(디폴트: ca-cert.pem)
certfile:
# 체인 파일
chainfile:CA에 이름을 붙이는 걸로 시작한다. 종종 이 이름은 CA가 서비스를 제공할 조직을 나타낸다. TLS CA라면 이름에 그 사실을 표시할 수 있다. 이 ca.name은 패브릭 CA 클라이언트가 --caname 파라미터 요청에 이 서버를 타겟팅하기 위해 사용된다.
이 CA에 대한 암호화 정보가 다른 곳에서 생성되었을 경우, 파일이 있는 경로(절대경로, 상대경로)와 함께 파일 이름을 제공할 수 있다. keyfile 파라미터는 개인키를, certfile은 공개키를 가리킨다.
chainfile 파라미터는 중간 CA에만 적용된다. 중간 CA를 시작할 때, 그 CA는 이 파라미터에 의해 지정된 장소에 체인파일을 만든다. 이 파일에는 root 인증서와 모든 중간 인증서들로 시작하는 신뢰 체인(trusted chain)의 인증서가 포함된다.
tls
tls:
# TLS 활성화 (디폴트: false)
enabled: true
# 서버 리스닝 포트에 대한 TLS
certfile:
keyfile:
clientauth:
type: noclientcert
certfiles:CA에 대한 TLS 커뮤니케이션을 활성화시키기 위해 이 섹션을 구성한다. TLS가 활성화된 후, CA와 거래하는 모든 노드들 또한 TLS를 활성화시켜야 한다.
-
tls.enabled: 안전한 프로덕션 환경을 위해, 구성 파일tls섹션에서enabled: true를 설정해야 한다. 이 설정으로 TLS는 활성화되고 안전한 노드 간 커뮤니케이션이 가능해진다. (테스트 환경에서 허용되는 '비활성화'가 TLS 디폴트 값이지만 프로덕션을 위해서는 활성화 시켜야 한다.) 이 설정은server-side TLS를 구성할 것이다. 이것은 TLS가 서버의 신원을 클라이언트에게 보장하고 그들 사이의 양방향 암호화 채널을 제공할 것임을 뜻한다. -
tls.certfile: 모든 CA는 TLS CA에 기재(register)하고 등록(enroll)해야 조직의 다른 노드와 안전하게 거래할 수 있다. 따라서 조직 CA나 중간 CA를 배포하기 전에 TLS CA를 배포하고, 조직 CA 부트스트랩 신원을 기재하고 등록해 조직 CA의 TLS 서명된 인증서를 생성해야 한다. 패브릭 CA 클라이언트를 이 인증서를 만들기 위해 사용할 때, TLS 서명된 인증서는FABRIC_CA_CLIENT_HOME폴더의 지정된 msp 디렉토리의signedcerts폴더에 생성된다. (예:/msp/signcerts/cert.pem). 그리고 이tls.certfile에서 생성된 TLS 서명 인증서의 위치와 이름을 제공한다. 만약 이 CA가 root TLS CA라면 이 필드는 공란일 수 있다. -
tls.keyfile:tls.certfile과 유사하게, 생성된 TLS 개인 키의 위치와 이름을 제공한다. (예:/msp/keystore/87bf5eff47d33b13d7aee81032b0e8e1e0ffc7a6571400493a7c_sk). 만약 HSM을 이용하거나 이 CA가 root TLS CA인 경우 이 필드는 공란일 수 있다.
주의 : 프로덕션 네트워크에서는 최소한 server-side TLS가 활성화되어야 한다.
만약 server-side TLS가 요구사항을 충분히 만족시킨다면 이 세션은 여기까지만 읽어도 된다. 네트워크의 mutual TLS 사용이 필요하다면 아래 두 필드를 구성해야 한다. (mutual TLS는 기본적으로 비활성화되어 있다).
tls.clientauth.type: 서버가 클라이언트의 신원을 추가로 인증해야 하는 경우 mutual TLS(mTLS)가 필요하다. mTLS를 구성하기 위해 클라이언트는 TLS 핸드셰이크가 일어나는 동안 자신의 인증서를 전송해야 한다. mTLS를 위한 CA를 구성하기 위해clientauth.type을RequireAndVerifyClientCert로 지정하라.tls.clientauth.certfiles: mTLS를 사용하는 경우에만, PEM으로 인코딩 된 root 인증서 인증 리스트를 제공한다. 이 리스트는 서버가 클라이언트 인증서를 검증할 때 사용된다. dashed yaml 리스트에 인증서를 지정하라.
cafiles
cafiles:CA 계획에서 언급했듯이, cafiles 파라미터는 dual-headed CA 구성에 사용될 수 있다. dual-headed CA란 단일 CA가 조직 CA와 TLS CA역할을 모두 하는 것을 뜻한다. 이 패턴은 편의를 위한 것으로, 각 CA가 자신의 구성을 유지하면서 동일한 백엔드 유저 데이터베이스를 공유할 수 있도록 해 준다. cafiles 파라미터에 두번째 CA 서버(예를 들어 TLS CA)의 fabric-ca-server-config.yaml 파일 경로를 입력해라. 두번째 CA의 구성은 port와 tls 섹션을 제외하고 첫번째 CA 서버의 구성 파일과 동일한 요소를 모두 포함할 수 있다. 만약 이 구성을 원하지 않는다면 이 파라미터를 공란으로 남겨둘 수 있다.
intermediate CA
intermediate:
parentserver:
url:
caname:
enrollment:
hosts:
profile:
label:
tls:
certfiles:
client:
certfile:
keyfile:Intermediate CA는 반드시 필요한 요소는 아니지만 조직 (root) CA가 손상될 위험을 줄이기 위해 하나 이상의 중간 CA를 네트워크에 포함시킬 수 있다.
중요 : 중간 CA 설정 전에 부모 CA의 csr.ca.pathlength 값을 검증해야 한다. 0으로 설정되면 조직 CA는 중간 CA 인증서를 발급할 수 있지만 그 중간 CA는 다른 중간 CA를 등록할 수 없다. 중간 CA가 다른 중간 CA를 등록할 수 있게 하려면 root CA의 csr.ca.pathlength 값은 1로 설정되어야 한다. 그리고 위에서 중간 CA로 등록된 중간 CA가 다른 중간 CA를 등록하고 싶다면 csr.ca.pathlength는 2가 되어야 한다.
parentserver.url: 부모 서버 url을https://<PARENT-CA-ENROLL-ID>:<PARENT-CA-SECRET>@<PARENT-CA-URL>:<PARENT-CA-PORT>형식으로 지정한다.parentserver.caname: 부모 서버의ca.name를 입력해야 한다enrollment.profile: 부모 CA의signing.profile값을 입력해야 한다. 일반적으로ca가 되어야 한다.tls.certfiles: TLS CA 서명 인증서(ca-cert.pem 파일)의 이름과 위치를 입력해야 한다. (예:tls/ca-cert.pem). 이 위치는 서버 구성 .yaml 파일 위치와 관련되어 있다.
중간 CA 사용을 위해서는 이 intermediate 섹션을 편집하는 것 외에도 구성 .yaml 파일의 아래 섹션을 편집해야 한다.
csr:csr.cn필드가 공란인지 확인해야 한다.port: 중간 CA를 위한 유니크 포트가 설정되어 있는지 확인해야 한다.signing:isca가true로 설정되어 있는지 확인해야 한다. 그리고 중간 CA가 다른 중간 CA의 부모 CA역할을 할 때에는maxpathlen가0보다 커야 하고 그렇지 않을 때는0으로 설정되어야 한다. signing 파라미터를 확인하라.
port
port:각 CA는 자신의 유니크한 포트에서 구동되어야 하고 다른 서비스가 같은 포트에서 충돌해서는 안 된다. CA가 어떤 포트에서 구동될지 미리 정하고 .yaml 파일에서 포트를 구성해야 한다.
user registry
# password/secret이 등록에 재사용될 수 있는 최대 횟수
# (디폴트: -1, 제한이 없음을 나타낸다.)
maxenrollments: -1
# LDAP가 비활성화되어 있을 때 사용되는 신원 정보
identities:
- name: <<<adminUserName>>>
pass: <<<adminPassword>>>
type: client
affiliation: ""
attrs:
hf.Registrar.Roles: "*"
hf.Registrar.DelegateRoles: "*"
hf.Revoker: true
hf.IntermediateCA: true
hf.GenCRL: true
hf.Registrar.Attributes: "*"
hf.AffiliationMgr: trueLDAP 유저 레지스트리를 사용하지 않는다면 이 세션이 연관된 레지스트리 데이터베이스 db: 섹션과 함께 필요하다. 이 섹션은 서버가 시작될 때 CA와 함께 유저 리스트를 기재(register)하는 데에 사용된다. 이것은 단순히 유저들을 기재할 뿐 그들을 위한 등록(enrollment) 인증서를 생성하지는 않는다. 연관된 등록 인증서 생성을 위해서는 패브릭 CA 클라이언트를 사용한다.
maxenrollments: 등록 ID와 secret을 사용해 한 유저에 대한 인증서를 생성할 수 있는 횟수 제한. reenroll 커맨드를 사용해 제한 없이 인증서를 얻을 수 있다.identities: 이 섹션은 CA가 시작될 때 등록될 유저들과 그들의 속성을 정의한다.fabric-ca-server init커맨드를 실행한 후, 여기 있는<<<adminUserName>>>와<<<adminPassword>>>는 커맨드의-b옵션으로 지정된 부트스트랩 신원 유저와 비밀번호로 대체된다.identities.type: 패브릭에서 유효한 타입은client,peer,admin,orderer, 그리고member이다.affiliation: 연결된name:파라미터로 지정된 유저와 연관된 소속(affiliation)을 지정해야 한다. 가능한 소속(affiliation) 리스트는affiliation:섹션에서 정의된다.attrs: 위에 포함된 기능들은 다른 유저들을 기재, 등록하는 "관리자" 유저를 위한 것이다. 만약 관리자가 아닌 유저를 기재한다면 위 권한들을 허가해서는 안 된다. 신원과 관련된hf속성은 해당 신원이 다른 유저를 기재하는 기능에 영향을 준다. 요구되는 패턴을 이해하기 위해서는 새 신원 기재하기 주제를 살펴보아야 한다.
유저가 이후에 등록되면 type, affiliation, attrs는 유저의 서명 인증서에서 볼 수 있고, 등록 인증을 위한 정책에서 사용한다. enrollment는 패브릭 CA가 신원을 형성하는 서명 인증서와 개인 키로 구성된 인증서 키-페어를 발급하는 과정이다. 개인 키와 공개키는 처음에 패브릭 CA 클라이언트에 의해 로컬로 처음 생성되고, 공개키는 CA로 전달되며 CA는 암호화된 인증서인 서명 인증서를 반환한다.
유저가 기재된 후, Identity 커맨드를 사용해 유저의 특성을 수정할 수 있다.
registry database
db:
type: sqlite3
datasource: fabric-ca-server.db
tls:
enabled: false
certfiles:
client:
certfile:
keyfile:패브릭 CA는 유저의 신원, 소속, 신임장, 그리고 공인 인증서를 데이터베이스에 저장한다. 이 섹션을 사용해 CA 데이터 저장에 사용되는 데이터베이스 타입을 지정한다. 패브릭은 아래 타입을 지원한다 :
sqlite(SQLite Version 3)postgres(PostgresSQL)mysql(MySQL)
만약 데이터베이스를 클러스터에서 가동하고 싶다면 postgres나 mysql을 선택해야 한다.
LDAP가 유저 레지스트리로 사용되고 있다면 (ldap.enabled:true로 지정된다) 이 섹션은 무시된다.
LDAP
ldap:
# LDAP client를 활성화/비활성화시킨다 (default: false)
# true로 지정되면 "registry" 섹션은 무시된다.
enabled: false
# LDAP 서버 URL
url: ldap://<adminDN>:<adminPassword>@<host>:<port>/<base>
# 클라이언트 - LDAP 서버 커넥션을 위한 TLS 구성
tls:
certfiles:
client:
certfile:
keyfile:
# LDAP 엔트리에서 패브릭 CA 속성으로 매핑하는 것과 관련된 속성들
attribute:
# 'names'은 LDAP 서버에서 LDAP 신원들의 엔트리를 위해 요청한느 LDAP 속성 이름을 포함한 string 배열이다.
names: ['uid','member']
# 'converters' 섹션은 LDAP 엔트리를 패브릭 CA 속성으로 변환하기 위해 쓰인다.
# 예: 아래 예시는 LDAP 값이 'revoker'로 시작되는 'uid' 속성을 값이 "true"인 "hf.Revoker" 패브릭 CA 속성으로 변환한다.
# converters:
# - name: hf.Revoker
# value: attr("uid") =~ "revoker*"
converters:
- name:
value:
# 'maps' 섹션은 'converters' 섹션의 'map' function에 의해 참조될 수 있는
# 이름붙여진 맵을 포함한다. 이것은 LDAP 리스폰스를 임시 값으로 매핑한다.
# 예: 한 유저가 각각이 고유한 이름인 (즉, DN인) 여러 값을 가지는
# 'member' LDAP 속성을 가지고 있다고 가정한다.
# 'member' 속성의 값들은 단순하게 'dn1', 'dn2', 'dn3'으로 가정한다.
#
# 또한 다음 구성을 가정한다.
# converters:
# - name: hf.Registrar.Roles
# value: map(attr("member"),"groups")
# maps:
# groups:
# - name: dn1
# value: peer
# - name: dn2
# value: client
# 유저의 'hf.Registrar.Roles' 속성 값은 "peer,client,dn3"으로 계산된다.
# 이는 'attr("member")'의 값이 "dn1,dn2,dn3"이고,
# 'map'을 호출하는 것이 "group"의 두번째 아규먼트 "dn1"를 "peer"로 대체하고
# "dn2"를 "client"로 대체하기 때문이다.
maps:
groups:
- name:
value:만약 LDAP 레지스트리가 구성되면 registry 세션의 모든 설정은 무시된다.
affiliations
affiliations:
org1:
- department1
- department2
org2:
- department1소속(affiliation)은 조직의 하부 부서를 디자인하는데에 효과적이다. 이후 정책 정의에 의해 참조될 수 있다. 예를 들어 ORG1 구성원일 뿐만 아니라 ORG1.MANUFACTURING 구성원인 피어가 트랜젝션을 보증하도록 할 때 사용할 수 있다. 기재하는 신원(registrar)의 소속은 기재되는 신원의 소속과 같거나 기재하는 신원의 소속의 접두사여야 한다. 소속 사용을 고려하고 있다면 요구 사항 확인을 위해 새 신원 기재하기 항목을 검토해야 한다. MSP에서 소속이 사용되는 방법에 대해 더 알고 싶다면 조직 유닛(OUs) 와 MSPs 항목에서 MSP 키 컨셉을 살펴보아라.
위에 나열된 기본 소속은 서버가 처음 시작될 때 패브릭 CA 데이터베이스에 추가된다. 서버에 소속을 갖지 않길 바란다면 서버를 처음 시작하기 전에 이 구성파일을 수정해서 이 항목을 지우거나 대체해야 한다. 그렇지 않다면 패브릭 CA 클라이언트 affiliation command를 사용해 소속 목록을 수정해야 한다. 디폴트로 소속은 구성에서 제거할 수 없으며 구성 요소들을 명시적으로 활성화해야 한다. 소속 구성 제거를 허가하는 구성 방법은 cfg세션을 참조해라.
csr
csr:
cn: <<<COMMONNAME>>>
keyrequest:
algo: ecdsa
size: 256
names:
- C: US
ST: "North Carolina"
L:
O: Hyperledger
OU: Fabric
hosts:
- <<<MYHOST>>>
- localhost
ca:
expiry: 131400h
pathlength: <<<PATHLENGTH>>>CSR(certificate signing request; 인증서 서명 요청) 섹션은 root CA 인증서 생성을 컨트롤한다. 즉, 이 섹션의 값을 사용자 정의 값으로 변경하려면 서버를 처음 시작하기 전 이 섹션을 구성하도록(변경하도록) 추천한다. 이곳에서 지정한 값은 생성되는 서명 인증서에 포함된다. 만약 서버가 시작된 후 CSR 값을 변경하려면 ca.cert 파일과 ca.key 파일을 먼저 제거하고 다시 fabric-ca-server start 명령어를 실행시켜야 한다.
csr.cn: 반드시 CA 부트스트랩 신원의 ID로 설정하거나 공란이 채 두어야 한다. 디폴트 값은 CA 서버 부트스트랩 신원이다.csr.keyrequest: 암호화 알고리즘과 키 사이즈를 사용자정의하고 싶을 때 사용한다.csr.names: 인증서 발행인에게 사용할 값을 지정한다. 서명 인증서에서 볼 수 있다.csr.hosts: 서버가 동작할 호스트 이름을 제공한다.csr.expiry: CA의 root 인증서가 만기되는 시점을 지정한다. 디폴트는131400h으로, 15년이다.csr.pathlength: 만약 중간 CA를 갖고 있다면, root CA에서 이 값을1로 지정해야 한다. 이 구성 파일이 중간 CA를 위한 것이라면, 해당 중간 CA가 다른 중간 CA의 부모 CA가 되지 않는 이상0으로 값을 설정할 수 있다.
signing
signing:
default:
usage:
- digital signature
expiry: 8760h
profiles:
ca:
usage:
- cert sign
- crl sign
expiry: 43800h
caconstraint:
isca: true
maxpathlen: 0
maxpathlenzero: true
tls:
usage:
- signing
- key encipherment
- server auth
- client auth
- key agreement
expiry: 8760h이 섹션의 디폴트는 일반적인 프로덕션 서버의 요구사항을 만족시킨다. 하지만 생성된 조직 CA와 TLS 인증서의 디폴트 만료일을 수정하고 싶을 수 있다. 이것은 csr섹션에서 expiry로 지정된 CA root 인증서 만료일과 다르다는 것에 주의하라.
만약 이것이 TLS CA라면 ca 섹션을 profiles: 에서 제거하는 것을 추천한다. TLS CA는 오직 TLS 인증서만을 발급하기 때문이다.
만약 둘 중간 CA 레벨을 계획하고 있다면 root CA의 구성 .yaml 파일에서 maxpathlen를 0보다 크게 설정해야 한다. 이 필드는 인증서 체인에서 이 인증서에 뒤따라 올 수 있는, 자체 발행되지 않은 중간 인증서들의 최대 수를 반영한다. 예를 들어, 이 root CA 아래에 중간 CA를 오게 할 계획이라면 maxpathlen은 0으로 설정될 수 있지만, 중간 CA가 다른 중간 CA의 부모 CA가 되는 경우에는 maxpathlen은 1로 지정되어야 한다. maxpathlen을 0으로 강제 지정하기 위해 maxpathlenzero를 true로 설정할 수 있다. 만약 maxpathlen이 0보다 크다면 maxpathlenzero는 false가 되어야 한다.
bccsp
bccsp:
default: SW
sw:
hash: SHA2
security: 256
filekeystore:
# 소프트웨어 파일기반 키 저장소에 사용되는 디렉토리
# (The directory used for the software file-based keystore)
keystore: msp/keystore이 섹션의 정보는 CA 개인키가 저장될 위치를 컨트롤한다. 위 구성은 개인키가 msp/keystore 폴더의 CA 서버 파일 시스템에 저장되게 한다. 하드웨어 보안 모듈(Hardware Security Module; HSM) 사용을 계획하고 있다면 구성은 다르게 이루어져야 한다. CA를 위한 HSM을 구성하면, CA 개인키는 msp/keystore 폴더 대신 HSM에 의해 생성되고 그곳에 저장된다.
softHSM을 위한 HSM 구성 예는 다음과 유사하다 :
bccsp:
default: PKCS11
pkcs11:
Library: /etc/hyperledger/fabric/libsofthsm2.so
Pin: 71811222
Label: fabric
hash: SHA2
security: 256
Immutable: falsecors
cors:
enabled: false
origins:
- "*"Cross-Origin Resource Sharing (CORS)가 구성될 수 있다. 이것은 추가 HTTP헤더를 사용해 브라우저에게 한 origin에서 실행되는 웹 애플리케이션에 다른 origin에서 선택된 리소스에 대한 접근 권한을 주도록 명령할 수 있다. origin 파라미터는 리소스 접근이 허가된 도메인 목록을 가진다.
cfg
cfg:
affiliations:
allowremove: false
identities:
allowremove: false 이 두 파라미터는 샘플 구성 파일에 나열되어 있지 않지만 이해하는 것이 중요하다. false로 설정된 디폴트 구성으로는 서버를 재시작하지 않고 소속이나 신원을 제거할 수 없다. 서버 재시작 없이 프로덕션 환경에서 소속이나 신원을 제거할 필요가 있다고 예상된다면, 서버를 시작하기 전에 이 두 필드를 모두 true로 설정해야 한다. 서버가 시작된 후에는 소속과 신원은 패브릭 CA 클라이언트 CLI 커맨드를 통해서만 수정할 수 있다는 점을 주의해라.
operations
operations:
# 운영 서버(operations server)용 host와 port
listenAddress: 127.0.0.1:9443
# 운영 엔드포인트(operations endpoint) TLS 구성
tls:
# TLS 활성화
enabled: false
# 운영 서버의 PEM 인코딩된 서버 인증서 경로
cert:
file:
# 운영 서버의 PEM 인코딩된 서버 키 경로
key:
file:
# 모든 리소스에 접근하기 위해 클라이언트 인증서 인증을 요구하는지 여부
clientAuthRequired: false
# 클라이언트 인증을 위한, 신뢰할 수 있는 PEM 인코딩된 CA 인증서 경로
# (paths to PEM encoded ca certificates to trust for client authentication)
clientRootCAs:
files: []운영 서비스는 CA 상태 모니터링에 사용할 수 있다. 이것은 노드와의 통신을 위해 상호 TLS에 의존한다. 즉, operations.tls.clientAuthRequired을 true로 설정할 필요가 있다. 이것이 true로 설정되면, 노드 상태를 확인하려는 클라이언트는 인증을 위해 유효한 인증서를 제공해야 한다. 만약 클라이언트가 인증서를 제공하지 않거나 서비스가 클라이언트의 인증서를 검증하지 못하면 요청이(request가) 거절된다. 이것은 클라이언트가 TLS CA에 기재(register)되어 있고, 요청에 자신의 TLS 서명 인증서를 제공해야 한다는 것을 의미한다.
두 CA가 같은 기기에서 구동되는 경우, 두번째 CA가 다른 포트를 사용하도록 listenAddress:를 수정해야 한다. 그렇지 않으면 두번째 CA를 시작할 때 the bind address is already in use 가 보고되며 시작에 실패할 것이다.
metrics
# statsd, prometheus, 또는 disabled
provider: disabled
# statsd 구성
statsd:
# network type: tcp 또는 udp
network: udp
# statsd server address
address: 127.0.0.1:8125
# 로컬로 캐시된 카운터와 게이지가 푸시되는 간격
# statsd에 대해; 타이밍은 즉시 푸시된다
writeInterval: 10s
# prefix(접두사)가 모든 내보내진 statsd metrics 앞에 붙여진다.
prefix: server만약 CA 메트릭을 모니터하기 원한다면 메트릭 공급자(provider)를 선택해야 한다 :
provider:statsd는 push 모델이고prometheus는 pull 모델이다. Prometheus는 pull 모델이기 때문에 패브릭 CA 서버사이드에서 필요한 구성은 없다. Prometheus는 운영 URL에 메트릭를 폴링하기 위한 요청을 보낸다. 가능한 메트릭 을 확인해라.
다음 단계
CA 구성을 결정하면 CA를 배포할 준비가 된 것이다. 다음 CA 배포 단계 토픽에 있는 설명을 따라 CA를 시작해라.
