데이터 접근 보안

데이터 접근 보안 (Securing Access To Your Data)

이 문서는 HBase의 데이터 자체를 보호하는 여러 전략을 설명해요. 역할 기반 접근 제어(RBAC), 가시성 레이블(Visibility Labels), 저장 상태 데이터의 투명한 암호화를 다뤄요. 클라이언트와 서버, 게이트웨이 간의 보안 인증을 구성한 후 데이터 자체의 보안을 고민하는 단계에서 읽으면 좋아요.

출처: 문서

본문

HBase 클라이언트와 서버 프로세스 및 게이트웨이 간의 보안 인증을 구성한 후에는 데이터 자체의 보안을 고려해야 해요. HBase는 데이터 보안을 위한 몇 가지 전략을 제공해요.

  • 역할 기반 접근 제어(RBAC) — 역할이라는 친숙한 패러다임을 사용해 어떤 사용자나 그룹이 주어진 HBase 리소스를 읽고 쓸 수 있는지, 또는 coprocessor 엔드포인트를 실행할 수 있는지 제어해요.
  • 가시성 레이블 — 셀에 레이블을 붙이고 레이블이 있는 셀에 대한 접근을 제어해서, 데이터의 특정 하위 집합을 누가 읽거나 쓸 수 있는지 더 제한할 수 있게 해 줘요. 가시성 레이블은 태그로 저장돼요. 자세한 내용은 hbase.tags를 참고하세요.
  • 저장 데이터의 투명한 암호화 — 기본 파일 시스템의 저장 데이터(HFiles와 WAL 모두)를 암호화해요. 클라이언트 구현을 변경할 필요 없이 기본 파일 시스템에 접근할 수 있는 공격자로부터 저장 데이터를 보호해요. 부적절하게 폐기된 디스크에서의 데이터 유출도 방지할 수 있는데, 법적·규제 준수에 중요할 수 있어요.

각 기능의 서버 측 구성, 관리, 구현 세부사항과 성능 상충 관계를 아래에서 다뤄요. 실제 시나리오처럼 모든 기능을 함께 사용하는 예시 보안 구성은 마지막에 제공돼요.

HBase의 보안의 모든 측면은 활발히 개발 중이며 빠르게 진화해요. 데이터 보안을 위해 채택하는 어떤 전략도 철저히 테스트해야 해요. 또한 이 기능 중 일부는 아직 개발 실험 단계예요. 이 기능 중 많은 것을 활용하려면 HBase 0.98+를 실행하고 HFile v3 파일 형식을 사용해야 해요.

이 섹션의 여러 절차는 클러스터 노드 간 파일 복사를 요구해요. 키, 구성 파일 또는 민감한 문자열을 포함한 다른 파일을 복사할 때는 ssh 같은 안전한 방법을 사용해 민감한 데이터가 유출되지 않게 하세요.

절차: 기본 서버 측 구성

hbase-site.xml에서 hfile.format.version을 3으로 설정해 HFile v3를 활성화하세요. 이것은 HBase 1.0 이상의 기본값이에요.

<property>
  <name>hfile.format.version</name>
  <value>3</value>
</property>

security.prerequisites와 ZooKeeper에 설명된 대로 RPC와 ZooKeeper에 SASL 및 Kerberos 인증을 활성화하세요.

태그

*태그(Tags)*는 HFile v3의 기능이에요. 태그는 키, 값, 버전과 별개로 셀의 일부인 메타데이터 조각이에요. 태그는 셀 수준 ACL과 가시성 레이블 같은 다른 보안 관련 기능의 기반을 제공하는 구현 세부사항이에요. 태그는 HFiles 자체에 저장돼요. 미래에는 태그를 사용해 다른 HBase 기능을 구현할 수도 있어요. 태그가 활성화하는 보안 기능을 사용하기 위해 태그에 대해 많이 알 필요는 없어요.

구현 세부사항

모든 셀은 0개 이상의 태그를 가질 수 있어요. 모든 태그는 타입과 실제 태그 바이트 배열을 가져요.

row key, column family, qualifier, 값이 인코딩될 수 있듯이(data.block.encoding.types 참고) 태그도 인코딩될 수 있어요. column family 수준에서 태그 인코딩을 활성화하거나 비활성화할 수 있고 기본적으로 활성화돼 있어요. column family에서 인코딩 설정을 관리하려면 HColumnDescriptor#setCompressionTags(boolean compressTags) 메서드를 사용하세요. 태그 인코딩이 적용되려면 column family에 대해 DataBlockEncoder도 활성화해야 해요.

hbase-site.xml에서 hbase.regionserver.wal.tags.enablecompression 값을 true로 설정하면, WAL 압축도 활성화된 경우 WAL의 각 태그 압축을 활성화할 수 있어요. 태그 압축은 사전 인코딩(dictionary encoding)을 사용해요.

RegionServer에서 서버 측으로 실행되는 Coprocessor는 셀 태그에 대해 get과 set 연산을 수행할 수 있어요. 태그는 읽기 응답이 다시 보내지기 전에 RPC 계층에서 제거되므로 클라이언트는 이 태그를 보지 못해요. WAL 암호화를 사용할 때는 태그 압축이 지원되지 않아요.

접근 제어 레이블(ACL)

동작 방식

HBase의 ACL은 사용자의 그룹 멤버십이나 그룹 배제, 그리고 주어진 그룹이 주어진 리소스에 접근할 수 있는 권한을 기반으로 해요. ACL은 AccessController라는 coprocessor로 구현돼요.

HBase는 사적인 그룹 매핑을 유지하지 않고 Hadoop 그룹 매퍼에 의존해요. 이 매퍼는 LDAP나 Active Directory 같은 디렉터리의 엔티티와 HBase 사용자를 매핑해요. 지원되는 어떤 Hadoop 그룹 매퍼든 동작해요. 그러면 사용자에게 리소스(글로벌, 네임스페이스, 테이블, 셀, 또는 엔드포인트)에 대한 특정 권한(Read, Write, Execute, Create, Admin)이 부여돼요.

Kerberos와 접근 제어가 활성화되면 HBase에 대한 클라이언트 접근은 인증되고, 명시적으로 부여되지 않은 한 사용자 데이터는 사적이에요.

HBase는 관계형 데이터베이스보다 특히 클라이언트 연산 측면에서 더 단순한 보안 모델을 가져요. 예를 들어 insert(새 레코드)와 update(기존 레코드) 사이에 구분이 없는데, 둘 다 Put으로 축약되기 때문이에요.

접근 수준 이해

HBase 접근 수준은 서로 독립적으로 부여되며 주어진 범위(scope)에서 다양한 유형의 연산을 허용해요.

  • Read (R) — 주어진 범위에서 데이터를 읽을 수 있음
  • Write (W) — 주어진 범위에서 데이터를 쓸 수 있음
  • Execute (X) — 주어진 범위에서 coprocessor 엔드포인트를 실행할 수 있음
  • Create (C) — 주어진 범위에서 테이블을 만들거나(자신이 만들지 않은 것조차) drop할 수 있음
  • Admin (A) — 주어진 범위에서 클러스터 밸런싱이나 region 할당 같은 클러스터 연산을 수행할 수 있음

가능한 범위는:

  • Superuser — 슈퍼유저는 HBase에서 사용 가능한 어떤 연산이든 어떤 리소스에든 수행할 수 있어요. 클러스터에서 HBase를 실행하는 사용자가 슈퍼유저이며, HMaster의 hbase-site.xml에서 구성 프로퍼티 hbase.superuser에 할당된 어떤 프린시펄도 슈퍼유저예요.
  • Global — global 범위에서 부여된 권한은 admin이 클러스터의 모든 테이블에 대해 연산할 수 있게 해 줘요.
  • Namespace — namespace 범위에서 부여된 권한은 주어진 네임스페이스 내의 모든 테이블에 적용돼요.
  • Table — table 범위에서 부여된 권한은 주어진 테이블 내의 데이터 또는 메타데이터에 적용돼요.
  • ColumnFamily — ColumnFamily 범위에서 부여된 권한은 그 ColumnFamily 내의 셀에 적용돼요.
  • Cell — cell 범위에서 부여된 권한은 그 정확한 셀 좌표(key, value, timestamp)에 적용돼요. 이는 데이터와 함께 정책을 진화시킬 수 있게 해 줘요. 특정 셀의 ACL을 변경하려면 원본의 정확한 좌표에 새 ACL로 업데이트된 셀을 쓰면 돼요. 다중 버전 스키마를 가지고 있고 모든 보이는 버전의 ACL을 업데이트하려면 모든 보이는 버전에 대해 새 셀을 써야 해요. 애플리케이션이 정책 진화를 완전히 제어해요. 위 규칙의 예외는 append와 increment 처리예요. append와 increment는 연산에 ACL을 실을 수 있어요. 연산에 포함되어 있다면 append 또는 increment의 결과에 적용돼요. 그렇지 않으면 append나 increment하는 기존 셀의 ACL이 보존돼요.

접근 수준과 범위의 조합은 사용자에게 부여할 수 있는 가능한 접근 수준의 행렬을 만들어요. 프로덕션 환경에서는 접근 수준을 특정 작업을 수행하는 데 필요한 것의 관점에서 생각하는 것이 유용해요. 다음 목록은 일반적인 유형의 HBase 사용자에 대한 적절한 접근 수준을 설명해요. 주어진 사용자가 필요한 작업을 수행하는 데 요구되는 것보다 더 많은 접근을 부여하지 않는 것이 중요해요.

  • Superusers — 프로덕션 시스템에서는 HBase 사용자만 슈퍼유저 접근을 가져야 해요. 개발 환경에서는 관리자가 클러스터를 빠르게 제어하고 관리하기 위해 슈퍼유저 접근이 필요할 수 있어요. 그러나 이런 유형의 관리자는 보통 슈퍼유저보다는 Global Admin이어야 해요.

  • Global Admins — global admin은 작업을 수행하고 HBase의 모든 테이블에 접근할 수 있어요. 일반적인 프로덕션 환경에서 admin은 테이블 내 데이터에 대한 Read나 Write 권한이 없어야 해요.

  • Admin 권한이 있는 global admin은 밸런싱, region 할당/할당 해제, 명시적 메이저 컴팩션 호출 같은 클러스터 전체 연산을 수행할 수 있어요. 이것은 운영 역할이에요.

  • Create 권한이 있는 global admin은 HBase 내의 어떤 테이블이든 만들거나 drop할 수 있어요. 이것은 DBA 유형의 역할에 가까워요. 프로덕션 환경에서는 서로 다른 사용자가 Admin과 Create 권한 중 하나만 가질 가능성이 높아요.

    현재 구현에서 Admin 권한이 있는 Global Admin은 테이블에 대한 Read와 Write 권한을 스스로 부여하고 그 테이블의 데이터에 접근할 수 있어요. 이런 이유로 Global Admin 권한은 실제로 필요로 하는 신뢰할 수 있는 사용자에게만 부여하세요. 또한 Create 권한이 있는 Global Admin은 ACL 테이블에 Put 연산을 수행해 grant 또는 revoke를 시뮬레이션하고 Global Admin 권한에 대한 인가 검사를 우회할 수 있다는 점에 유의하세요. 이런 문제들 때문에 Global Admin 권한 부여에 신중해야 해요.

  • Namespace Admins — Create 권한이 있는 namespace admin은 그 네임스페이스 내에서 테이블을 만들거나 drop하고 스냅샷을 찍거나 복원할 수 있어요. Admin 권한이 있는 namespace admin은 그 네임스페이스 내 테이블에 대한 split이나 메이저 컴팩션 같은 연산을 수행할 수 있어요.

  • Table Admins — table admin은 그 테이블에 대해서만 관리 연산을 수행할 수 있어요. Create 권한이 있는 table admin은 그 테이블에서 스냅샷을 만들거나 스냅샷에서 그 테이블을 복원할 수 있어요. Admin 권한이 있는 table admin은 그 테이블에 대한 split이나 메이저 컴팩션 같은 연산을 수행할 수 있어요.

  • Users — 사용자는 데이터를 읽거나 쓰거나, 또는 둘 다 할 수 있어요. 사용자는 Executable 권한이 부여되면 coprocessor 엔드포인트도 실행할 수 있어요.

접근 수준의 실제 예시

Job Title Scope Permissions Description
Senior Administrator Global Access, Create 클러스터를 관리하고 Junior Administrators에게 접근을 부여해요.
Junior Administrator Global Create 테이블을 만들고 Table Administrators에게 접근을 부여해요.
Table Administrator Table Access 운영 관점에서 테이블을 유지 관리해요.
Data Analyst Table Read HBase 데이터에서 보고서를 만듭니다.
Web Application Table Read, Write HBase에 데이터를 넣고 HBase 데이터를 사용해 연산을 수행해요.

ACL 행렬

ACL이 특정 HBase 연산과 작업에 어떻게 매핑되는지에 대한 자세한 내용은 appendix acl matrix를 참고하세요.

구현 세부사항

셀 수준 ACL은 태그를 사용해 구현돼요(Tags 참고). 셀 수준 ACL을 사용하려면 HFile v3와 HBase 0.98 이상을 사용해야 해요.

  1. HBase가 만든 파일은 HBase 프로세스를 실행하는 운영체제 사용자가 소유해요. HBase 파일과 상호작용하려면 API나 bulk load 기능을 사용해야 해요.
  2. HBase는 내부적으로 "역할"을 모델링하지 않아요. 대신 그룹 이름에 권한을 부여할 수 있어요. 이것은 그룹 멤버십을 통한 외부 역할 모델링을 허용해요. 그룹은 HBase 외부에서 Hadoop 그룹 매핑 서비스를 통해 만들어지고 조작돼요.

서버 측 구성

사전 준비로 Procedure: Basic Server-Side Configuration의 단계를 수행하세요.

hbase-site.xml에서 다음 프로퍼티를 설정해 AccessController coprocessor를 설치하고 구성하세요. 이 프로퍼티들은 클래스 목록을 받아요.

AccessController를 VisibilityController와 함께 사용한다면 AccessController가 목록에서 먼저 와야 해요. 두 구성 요소가 활성 상태일 때 VisibilityController는 그 시스템 테이블에 대한 접근 제어를 AccessController에 위임하기 때문이에요. 둘을 함께 사용하는 예시는 Security Configuration Example을 참고하세요.

<property>
  <name>hbase.security.authorization</name>
  <value>true</value>
</property>
<property>
  <name>hbase.coprocessor.region.classes</name>
  <value>
    org.apache.hadoop.hbase.security.access.AccessController,
    org.apache.hadoop.hbase.security.token.TokenProvider
  </value>
</property>
<property>
  <name>hbase.coprocessor.master.classes</name>
  <value>org.apache.hadoop.hbase.security.access.AccessController</value>
</property>
<property>
  <name>hbase.coprocessor.regionserver.classes</name>
  <value>org.apache.hadoop.hbase.security.access.AccessController</value>
</property>
<property>
  <name>hbase.security.exec.permission.checks</name>
  <value>true</value>
</property>

선택적으로 hbase.rpc.protection을 privacy로 설정해 전송 보안을 활성화할 수 있어요. 이것은 HBase 0.98.4 이상을 요구해요.

Hadoop namenode의 core-site.xml에 Hadoop 그룹 매퍼를 설정하세요. 이것은 HBase 파일이 아니라 Hadoop 파일이에요. 사이트의 필요에 맞게 사용자 정의하세요. 다음은 예시예요.

<property>
  <name>hadoop.security.group.mapping</name>
  <value>org.apache.hadoop.security.LdapGroupsMapping</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.url</name>
  <value>ldap://server</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.bind.user</name>
  <value>[email protected]</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.bind.password</name>
  <value>****</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.base</name>
  <value>dc=example-ad,dc=local</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.search.filter.user</name>
  <value>(&(objectClass=user)(sAMAccountName={0}))</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.search.filter.group</name>
  <value>(objectClass=group)</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.search.attr.member</name>
  <value>member</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.search.attr.group.name</name>
  <value>cn</value>
</property>

선택적으로 early-out 평가 전략을 활성화하세요. HBase 0.98.0 이전에는 사용자가 column family 또는 최소한 column qualifier에 대한 접근을 부여받지 않았다면 AccessDeniedException이 발생했어요. HBase 0.98.0은 셀 수준의 예외적 부여를 허용하기 위해 이 예외를 제거했어요. HBase 0.98.0-0.98.6에서 옛 동작을 복원하려면 hbase-site.xml에서 hbase.security.access.early_out을 true로 설정하세요. HBase 0.98.6에서 기본값은 true로 돌아갔어요.

구성을 배포하고 변경 사항을 적용하려면 클러스터를 재시작하세요.

구성을 테스트하려면 주어진 사용자로 HBase Shell에 로그인하고 whoami 명령으로 사용자가 속한 그룹을 보고하세요. 이 예시에서 사용자는 services 그룹의 멤버로 보고돼요.

hbase> whoami
service (auth:KERBEROS)
    groups: services

관리

관리 작업은 HBase Shell 또는 API로 수행할 수 있어요.

아래의 많은 API 예시는 소스 파일 hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java와 hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/SecureTestUtil.java에서 가져온 것이에요.

예시도 그것이 가져온 소스 파일도 공용 HBase API의 일부가 아니며 설명 목적으로만 제공돼요. 사용 지침은 공식 API를 참고하세요.

사전 준비로 Procedure: Basic Server-Side Configuration.의 단계를 수행하세요.

hbase-site.xml에서 다음 프로퍼티를 설정해 AccessController coprocessor를 설치하고 구성하세요. 이 프로퍼티들은 클래스 목록을 받아요.

AccessController를 VisibilityController와 함께 사용한다면 AccessController가 목록에서 먼저 와야 해요.

<property>
  <name>hbase.security.authorization</name>
  <value>true</value>
</property>
<property>
  <name>hbase.coprocessor.region.classes</name>
  <value>
    org.apache.hadoop.hbase.security.access.AccessController,
    org.apache.hadoop.hbase.security.token.TokenProvider
  </value>
</property>
<property>
  <name>hbase.coprocessor.master.classes</name>
  <value>org.apache.hadoop.hbase.security.access.AccessController</value>
</property>
<property>
  <name>hbase.coprocessor.regionserver.classes</name>
  <value>org.apache.hadoop.hbase.security.access.AccessController</value>
</property>
<property>
  <name>hbase.security.exec.permission.checks</name>
  <value>true</value>
</property>

선택적으로 hbase.rpc.protection을 privacy로 설정해 전송 보안을 활성화할 수 있어요. 이것은 HBase 0.98.4 이상을 요구해요.

Hadoop namenode의 core-site.xml에 Hadoop 그룹 매퍼를 설정하세요. 이것은 HBase 파일이 아니라 Hadoop 파일이에요. 사이트의 필요에 맞게 사용자 정의하세요. 다음은 예시예요.

<property>
  <name>hadoop.security.group.mapping</name>
  <value>org.apache.hadoop.security.LdapGroupsMapping</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.url</name>
  <value>ldap://server</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.bind.user</name>
  <value>[email protected]</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.bind.password</name>
  <value>****</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.base</name>
  <value>dc=example-ad,dc=local</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.search.filter.user</name>
  <value>(&(objectClass=user)(sAMAccountName={0}))</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.search.filter.group</name>
  <value>(objectClass=group)</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.search.attr.member</name>
  <value>member</value>
</property>

<property>
  <name>hadoop.security.group.mapping.ldap.search.attr.group.name</name>
  <value>cn</value>
</property>

선택적으로 early-out 평가 전략을 활성화하세요. HBase 0.98.0 이전에는 사용자가 column family 또는 최소한 column qualifier에 대한 접근을 부여받지 않았다면 AccessDeniedException이 발생했어요. HBase 0.98.0은 셀 수준의 예외적 부여를 허용하기 위해 이 예외를 제거했어요. HBase 0.98.0-0.98.6에서 옛 동작을 복원하려면 hbase-site.xml에서 hbase.security.access.early_out을 true로 설정하세요. HBase 0.98.6에서 기본값은 true로 돌아갔어요.

구성을 배포하고 변경 사항을 적용하려면 클러스터를 재시작하세요.

구성을 테스트하려면 주어진 사용자로 HBase Shell에 로그인하고 whoami 명령으로 사용자가 속한 그룹을 보고하세요. 이 예시에서 사용자는 services 그룹의 멤버로 보고돼요.

hbase> whoami
service (auth:KERBEROS)
    groups: services

API 예시:

public static void verifyAllowed(User user, AccessTestAction action, int count) throws Exception {
  try {
    Object obj = user.runAs(action);
    if (obj != null && obj instanceof List<?>) {
      List<?> results = (List<?>) obj;
      if (results != null && results.isEmpty()) {
        fail("Empty non null results from action for user '" + user.getShortName() + "'");
      }
      assertEquals(count, results.size());
    }
  } catch (AccessDeniedException ade) {
    fail("Expected action to pass for user '" + user.getShortName() + "' but was denied");
  }
}

가시성 레이블

가시성 레이블 제어는 주어진 레이블과 연관된 사용자나 프린시펄만 해당 레이블이 있는 셀을 읽거나 접근하도록 허용하는 데 사용할 수 있어요. 예를 들어 셀에 top-secret 레이블을 붙이고 managers 그룹에만 그 레이블에 대한 접근을 부여할 수 있어요. 가시성 레이블은 HFile v3의 기능인 태그로 구현되며 셀별로 메타데이터를 저장할 수 있게 해 줘요. 레이블은 문자열이고, 레이블은 논리 연산자(&, |, !)를 사용하고 괄호로 그룹화해 식으로 결합할 수 있어요. HBase는 기본적인 well-formedness 외에는 어떤 종류의 식 검증도 하지 않아요. 가시성 레이블은 그 자체로 의미가 없으며 민감도 수준, 권한 수준 또는 다른 임의의 의미론적 의미를 나타내는 데 사용할 수 있어요.

사용자의 레이블이 셀의 레이블이나 식과 일치하지 않으면 사용자는 셀에 대한 접근이 거부돼요.

HBase 0.98.6 이상에서 가시성 레이블과 식에 UTF-8 인코딩이 지원돼요. org.apache.hadoop.hbase.security.visibility.VisibilityClient 클래스가 제공하는 addLabels(conf, labels) 메서드로 레이블을 만들고 Scan 또는 Get을 통해 Authorizations에 레이블을 전달할 때, 레이블은 가시성 레이블에서 보통 쓰이는 논리 연산자와 함께 UTF-8 문자를 포함할 수 있고, 이스케이프 방법 없이 일반 Java 표기법을 사용할 수 있어요. 그러나 Mutation을 통해 CellVisibility 식을 전달할 때는 UTF-8 문자나 논리 연산자를 사용한다면 식을 CellVisibility.quote() 메서드로 묶어야 해요. TestExpressionParser와 소스 파일 hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestScan.java를 참고하세요.

사용자는 Put 연산 중에 셀에 가시성 식을 추가해요. 기본 구성에서 사용자는 그 레이블로 셀에 레이블을 붙이기 위해 레이블에 대한 접근이 필요하지 않아요. 이 동작은 hbase.security.visibility.mutations.checkauths 구성 옵션으로 제어돼요. 이 옵션을 true로 설정하면 mutation의 일부로 수정하는 레이블이 사용자와 연관되어야 하며, 그렇지 않으면 mutation이 실패해요. 사용자가 레이블이 있는 셀을 읽을 권한이 있는지 여부는 Get 또는 Scan 중에 결정되고, 사용자가 읽을 수 없는 결과는 필터링돼요. 이것은 결과가 반환된 경우와 같은 I/O 비용이 발생하지만 네트워크 부하는 줄여요.

가시성 레이블은 Delete 연산 중에도 지정할 수 있어요. 가시성 레이블과 Deletes에 대한 자세한 내용은 HBASE-10885를 참고하세요.

사용자의 유효 레이블 집합은 RegionServer가 첫 요청을 받을 때 RPC 컨텍스트에서 구축돼요. 사용자가 레이블과 연관되는 방식은 플러그 가능해요. 기본 플러그인은 Get 또는 Scan에 추가된 Authorizations에 지정된 레이블을 통과시키고 그것을 호출하는 사용자의 인증된 레이블 목록과 대조해 확인해요. 클라이언트가 사용자가 인증되지 않은 레이블을 전달하면 기본 플러그인은 그것을 버려요. Get#setAuthorizations(Authorizations(String,...))와 Scan#setAuthorizations(Authorizations(String,...)); 메서드로 사용자 인증 레이블의 하위 집합을 전달할 수 있어요.

그룹은 사용자와 같은 방식으로 가시성 레이블을 부여받을 수 있어요. 그룹은 @ 기호로 접두사가 붙어요. 사용자의 가시성 레이블을 확인할 때 서버는 사용자가 멤버인 그룹의 가시성 레이블을 사용자 자신의 레이블과 함께 포함해요. VisibilityClient#getAuths API 또는 사용자의 get_auths 셸 명령으로 가시성 레이블을 검색하면 사용자 개인에게만 추가된 레이블을 반환하고 그룹 수준 레이블은 반환하지 않아요.

가시성 레이블 접근 확인은 VisibilityController coprocessor가 수행해요. VisibilityLabelService 인터페이스를 사용해 사용자 지정 구현을 제공하거나 가시성 레이블이 셀에 저장되는 방식을 제어할 수 있어요. 한 예시는 소스 파일 hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabelsWithCustomVisLabService.java를 참고하세요.

가시성 레이블은 ACL과 함께 사용할 수 있어요.

레이블은 가시성 레이블에 사용되기 전에 명시적으로 정의되어야 해요. 이것을 어떻게 하는지에 대한 예시는 아래를 참고하세요.

현재 셀에 어떤 레이블이 적용됐는지 확인할 방법은 없어요. 자세한 내용은 HBASE-12470을 참고하세요.

가시성 레이블은 현재 슈퍼유저에게 적용되지 않아요.

가시성 식의 예시

Expression Interpretation
fulltime fulltime 레이블과 연관된 사용자에게 접근 허용.
!public public 레이블과 연관되지 않은 사용자에게 접근 허용.
( secret | topsecret ) & !probationary secret 또는 topsecret 레이블과 연관되고 probationary 레이블과 연관되지 않은 사용자에게 접근 허용.

서버 측 구성

사전 준비로 Procedure: Basic Server-Side Configuration.의 단계를 수행하세요.

hbase-site.xml에서 다음 프로퍼티를 설정해 VisibilityController coprocessor를 설치하고 구성하세요. 이 프로퍼티들은 클래스 이름 목록을 받아요.

<property>
  <name>hbase.security.authorization</name>
  <value>true</value>
</property>
<property>
  <name>hbase.coprocessor.region.classes</name>
  <value>org.apache.hadoop.hbase.security.visibility.VisibilityController</value>
</property>
<property>
  <name>hbase.coprocessor.master.classes</name>
  <value>org.apache.hadoop.hbase.security.visibility.VisibilityController</value>
</property>

AccessController와 VisibilityController coprocessor를 함께 사용한다면 AccessController가 목록에서 먼저 와야 해요. 두 구성 요소가 활성 상태일 때 VisibilityController는 그 시스템 테이블에 대한 접근 제어를 AccessController에 위임하기 때문이에요.

구성 조정

기본적으로 사용자는 어떤 레이블로든 셀에 레이블을 붙일 수 있는데, 자신과 연관되지 않은 레이블도 포함돼요. 즉 사용자는 자신이 읽을 수 없는 데이터를 Put할 수 있어요. 예를 들어 사용자가 자신과 연관되지 않은 (가상의) 'topsecret' 레이블로 셀에 레이블을 붙일 수 있어요. 사용자가 자신과 연관된 레이블로만 셀에 레이블을 붙일 수 있게 하려면 hbase.security.visibility.mutations.checkauths를 true로 설정하세요. 그 경우 사용자가 연관되지 않은 레이블을 사용하면 mutation이 실패할 거예요.

구성을 배포하고 변경 사항을 적용하려면 클러스터를 재시작하세요.

관리

관리 작업은 HBase Shell이나 Java API를 사용해 수행할 수 있어요. 가시성 레이블 목록 정의와 사용자와의 레이블 연관에는 HBase Shell이 아마 더 단순해요.

이 섹션의 많은 Java API 예시는 소스 파일 hbase-server/src/test/java/org/apache/hadoop/hbase/security/visibility/TestVisibilityLabels.java에서 가져온 것이에요. 더 많은 컨텍스트는 그 파일이나 API 문서를 참고하세요.

이 예시들도 그것이 가져온 소스 파일도 공용 HBase API의 일부가 아니며 설명 목적으로만 제공돼요. 사용 지침은 공식 API를 참고하세요.

가시성 레이블 목록 정의

HBase Shell:

hbase> add_labels [ 'admin', 'service', 'developer', 'test' ]

Java API:

public static void addLabels() throws Exception {
  PrivilegedExceptionAction<VisibilityLabelsResponse> action = new PrivilegedExceptionAction<VisibilityLabelsResponse>() {
    public VisibilityLabelsResponse run() throws Exception {
      String[] labels = { SECRET, TOPSECRET, CONFIDENTIAL, PUBLIC, PRIVATE, COPYRIGHT, ACCENT,
          UNICODE_VIS_TAG, UC1, UC2 };
      try {
        VisibilityClient.addLabels(conf, labels);
      } catch (Throwable t) {
        throw new IOException(t);
      }
      return null;
    }
  };
  SUPERUSER.runAs(action);
}

레이블을 사용자와 연관시키기

HBase Shell:

hbase> set_auths 'service', [ 'service' ]
hbase> set_auths 'testuser', [ 'test' ]
hbase> set_auths 'qa', [ 'test', 'developer' ]
hbase> set_auths '@qagroup', [ 'test' ]

Java API:

public void testSetAndGetUserAuths() throws Throwable {
  final String user = "user1";
  PrivilegedExceptionAction<Void> action = new PrivilegedExceptionAction<Void>() {
    public Void run() throws Exception {
      String[] auths = { SECRET, CONFIDENTIAL };
      try {
        VisibilityClient.setAuths(conf, auths, user);
      } catch (Throwable e) {
      }
      return null;
    }
    ...

사용자에서 레이블 지우기

HBase Shell:

hbase> clear_auths 'service', [ 'service' ]
hbase> clear_auths 'testuser', [ 'test' ]
hbase> clear_auths 'qa', [ 'test', 'developer' ]
hbase> clear_auths '@qagroup', [ 'test', 'developer' ]

Java API:

...
auths = new String[] { SECRET, PUBLIC, CONFIDENTIAL };
VisibilityLabelsResponse response = null;
try {
  response = VisibilityClient.clearAuths(conf, auths, user);
} catch (Throwable e) {
  fail("Should not have failed");
  ...
}

셀에 레이블 또는 식 적용

레이블은 데이터가 쓰일 때만 적용돼요. 레이블은 셀의 주어진 버전과 연관돼요.

HBase Shell:

hbase> set_visibility 'user', 'admin|service|developer', { COLUMNS => 'i' }
hbase> set_visibility 'user', 'admin|service', { COLUMNS => 'pii' }
hbase> set_visibility 'user', 'test', { COLUMNS => [ 'i', 'pii' ], FILTER => "(PrefixFilter ('test'))" }

셀에 레이블이나 권한을 적용하기 위한 HBase Shell 지원은 테스트와 검증 지원용이에요. 아직 존재하지 않는 셀에 레이블을 적용하지 않으므로 프로덕션 사용에는 적합하지 않아요. 셀 수준 레이블을 적용하는 올바른 방법은 값을 저장할 때 애플리케이션 코드에서 하는 것이에요.

Java API 예시:

static Table createTableAndWriteDataWithLabels(TableName tableName, String... labelExps)
    throws Exception {
  Configuration conf = HBaseConfiguration.create();
  Connection connection = ConnectionFactory.createConnection(conf);
  Table table = NULL;
      try {
        table = TEST_UTIL.createTable(tableName, fam);
        int i = 1;
        List<Put> puts = new ArrayList<Put>();
        for (String labelExp : labelExps) {
          Put put = new Put(Bytes.toBytes("row" + i));
          put.add(fam, qual, HConstants.LATEST_TIMESTAMP, value);
          put.setCellVisibility(new CellVisibility(labelExp));
          puts.add(put);
          i++;
        }
        table.put(puts);
      } finally {
        if (table != null) {
          table.flushCommits();
        }
      }
    }

레이블이 있는 셀 읽기

Scan이나 Get을 발행하면 HBase는 기본 인가 집합을 사용해 접근할 수 없는 셀을 필터링해요. 슈퍼유저는 set_auths HBase Shell 명령이나 VisibilityClient.setAuths() 메서드로 주어진 사용자의 기본 인가 집합을 설정할 수 있어요.

Scan이나 Get 중에 HBase Shell의 AUTHORIZATIONS 옵션이나 API를 사용한다면 Scan.setAuthorizations() 메서드로 다른 인가를 지정할 수 있어요. 이 인가는 기본 집합과 결합되어 추가 필터가 돼요. 추가 인가를 주는 것이 아니라 결과를 더 필터링할 거예요.

HBase Shell:

hbase> get_auths 'myUser'
hbase> scan 'table1', AUTHORIZATIONS => ['private']

Java API:

...
public Void run() throws Exception {
  String[] auths1 = { SECRET, CONFIDENTIAL };
  GetAuthsResponse authsResponse = null;
  try {
    VisibilityClient.setAuths(conf, auths1, user);
    try {
      authsResponse = VisibilityClient.getAuths(conf, user);
    } catch (Throwable e) {
      fail("Should not have failed");
    }
  } catch (Throwable e) {
  }
  List<String> authsList = new ArrayList<String>();
  for (ByteString authBS : authsResponse.getAuthList()) {
    authsList.add(Bytes.toString(authBS.toByteArray()));
  }
  assertEquals(2, authsList.size());
  assertTrue(authsList.contains(SECRET));
  assertTrue(authsList.contains(CONFIDENTIAL));
  return null;
}
...

자신만의 가시성 레이블 알고리즘 구현

주어진 get/scan 요청에 대해 인증된 레이블을 해석하는 것은 플러그 가능한 알고리즘이에요.

hbase.regionserver.scan.visibility.label.generator.class 프로퍼티를 사용해 사용자 지정 플러그인을 지정할 수 있어요. 첫 번째 ScanLabelGenerator의 출력이 다음 것의 입력이 되고, 목록의 끝까지 그렇게 돼요.

HBASE-12466에서 구현된 기본 구현은 FeedUserAuthScanLabelGenerator와 DefinedSetFilterScanLabelGenerator 두 플러그인을 로드해요. Reading Cells with Labels를 참고하세요.

가시성 태그를 문자열로 복제하기

위 섹션에서 언급했듯이, VisibilityLabelService 인터페이스는 셀에 가시성 식을 저장하는 다른 방법을 구현하는 데 사용할 수 있어요. 복제가 활성화된 클러스터는 가시성 식도 피어 클러스터로 복제해야 해요. DefaultVisibilityLabelServiceImpl을 VisibilityLabelService의 구현으로 사용하면 모든 가시성 식은 labels 테이블에 저장된 각 가시성 레이블의 서수(ordinal)에 기반한 해당 식으로 변환돼요. 복제 중에 보이는 셀은 서수 기반 식이 온전한 채로 복제돼요. 피어 클러스터는 가시성 레이블에 대해 같은 서수 매핑을 가진 같은 labels 테이블을 가지지 못할 수 있어요. 그 경우 서수를 복제하는 것은 의미가 없어요. 가시성 식이 문자열로 전송되는 상태로 복제가 발생하면 더 좋아요. 가시성 식을 문자열로 피어 클러스터에 복제하려면 VisibilityLabelService 인터페이스의 구현에 기반해 동작하는 RegionServerObserver 구성을 만드세요. 아래 구성은 가시성 식을 문자열로 피어 클러스터에 복제할 수 있게 해 줘요. 자세한 내용은 HBASE-11639를 참고하세요.

<property>
  <name>hbase.security.authorization</name>
  <value>true</value>
</property>
<property>
  <name>hbase.coprocessor.regionserver.classes</name>
  <value>org.apache.hadoop.hbase.security.visibility.VisibilityController$VisibilityReplication</value>
</property>

저장 데이터의 투명한 암호화

HBase는 HDFS 또는 다른 분산 파일 시스템에 있는 HFiles와 WAL의 저장 데이터를 보호하는 메커니즘을 제공해요. 유연하고 비침습적인 키 회전을 위해 2계층 아키텍처가 사용돼요. "투명하다"는 것은 클라이언트 측에서 구현 변경이 필요 없다는 뜻이에요. 데이터가 쓰일 때 암호화되고, 읽힐 때 필요에 따라 복호화돼요.

동작 방식

관리자는 클러스터용 마스터 키를 프로비저닝하는데, 이 키는 HMaster, RegionServers, 관리 워크스테이션의 클라이언트(HBase Shell 같은)를 포함한 모든 신뢰하는 HBase 프로세스가 접근할 수 있는 키 제공자에 저장돼요. 기본 키 제공자는 Java KeyStore API와 그것을 지원하는 어떤 키 관리 시스템과도 통합돼요. 다른 사용자 지정 키 제공자 구현도 가능해요. 키 검색 메커니즘은 hbase-site.xml 구성 파일에 구성돼요. 마스터 키는 보안 KeyStore 파일로 보호된 클러스터 서버에 저장되거나, 외부 키서버에, 또는 하드웨어 보안 모듈에 저장될 수 있어요. 이 마스터 키는 구성된 키 제공자를 통해 HBase 프로세스가 필요에 따라 해석해요.

다음으로, column family별로 column descriptor를 만들거나 수정해 스키마에 암호화 사용을 지정할 수 있는데, 두 가지 추가 속성을 포함해요. 사용할 암호화 알고리즘 이름(현재는 "AES"만 지원)과 선택적으로 클러스터 마스터 키로 래핑(암호화)된 데이터 키예요. ColumnFamily에 데이터 키가 명시적으로 구성되지 않으면 HBase는 HFile별로 랜덤 데이터 키를 만들 거예요. 이것은 대안에 비해 보안을 점진적으로 개선해요. 주어진 데이터 키로 벌크 임포트용 암호화된 HFiles를 생성하는 경우처럼 명시적 데이터 키를 제공해야 하는 경우가 아니라면, ColumnFamily 스키마 메타데이터에 암호화 알고리즘만 지정하고 HBase가 필요에 따라 데이터 키를 만들게 두세요. Column Family별 키는 영향이 낮은 점진적 키 회전을 용이하게 하고 키 자료의 외부 유출 범위를 줄여요. 래핑된 데이터 키는 ColumnFamily 스키마 메타데이터와 그 Column Family의 각 HFile에 저장되며, 클러스터 마스터 키로 암호화돼요. Column Family가 암호화용으로 구성된 후에는 어떤 새 HFiles든 암호화되어 작성돼요. 모든 HFile의 암호화를 보장하려면 이 기능을 활성화한 후 메이저 컴팩션을 트리거하세요.

HFile이 열리면 데이터 키가 HFile에서 추출되고 클러스터 마스터 키로 복호화되어 HFile의 나머지를 복호화하는 데 사용돼요. 마스터 키를 사용할 수 없으면 HFile은 읽을 수 없게 돼요. 원격 사용자가 HDFS 권한의 어떤 실수로 HFile 데이터에 접근하거나 부적절하게 버려진 미디어에서 가져온다 해도 데이터 키나 파일 데이터를 복호화하는 것은 불가능할 거예요.

WAL을 암호화하는 것도 가능해요. WAL은 일시적이지만, 기본 파일 시스템이 손상된 경우 암호화된 column family에 대한 HFile 보호를 우회하지 않도록 WALEdits를 암호화하는 것이 필요해요. WAL 암호화가 활성화되면 관련 HFile이 암호화되었는지 여부와 관계없이 모든 WAL이 암호화돼요.

기능 활성화 또는 비활성화

"저장 데이터의 투명한 암호화" 기능은 기본적으로 활성화돼 있어요. 즉 기능이 제대로 구성되었다고 가정하면(Server-Side Configuration 참고) 사용자는 HFiles와 WAL 파일이 HBase에 의해 암호화될 column family로 테이블을 정의할 수 있어요.

어떤 경우(예: 사용자 지정 보안 정책 때문에) HBase 클러스터 운영자가 HBase 밖의 저장 암호화 메커니즘(예: HDFS가 제공하는 것)에만 의존하고 HBase의 저장 암호화 시스템이 비활성 상태인지 확인하고 싶을 수 있어요. HBASE-25181부터 hbase.crypto.enabled를 false로 설정해 HBase 자체 암호화를 명시적으로 비활성화할 수 있어요. 이 구성은 기본적으로 true예요. false로 설정하면 사용자는 HFile과 WAL 파일 암호화로 어떤 테이블(column family)도 만들 수 없고, 관련 create table 셸(또는 API) 명령은 시도하면 실패할 거예요.

서버 측 구성

이 절차는 기본 Java keystore 구현을 사용한다고 가정해요. 사용자 지정 구현을 사용한다면 그 문서를 확인하고 그에 맞게 조정하세요.

keytool 유틸리티를 사용해 AES 암호화용으로 적절한 길이의 비밀 키를 만드세요.

$ keytool -keystore /path/to/hbase/conf/hbase.jks \
  -storetype jceks -storepass **** \
  -genseckey -keyalg AES -keysize 128 \
  -alias <alias>

****를 keystore 파일의 비밀번호로, 를 HBase 서비스 계정의 사용자 이름 또는 임의의 문자열로 바꾸세요. 임의의 문자열을 사용한다면 HBase가 그것을 사용하도록 구성해야 하는데, 아래에서 다뤄요. 적절한 keysize를 지정하세요. 키에 대해 별도 비밀번호를 지정하지 말고 프롬프트가 나타나면 Return을 누르세요.

keyfile에 적절한 권한을 설정하고 모든 HBase 서버에 배포하세요.

이전 명령은 HBase conf/ 디렉터리에 hbase.jks라는 파일을 만들었어요. HBase 서비스 계정 사용자만 이 파일을 읽을 수 있도록 이 파일에 권한과 소유권을 설정하고 키를 모든 HBase 서버에 안전하게 배포하세요.

HBase 데몬을 구성하세요.

region servers의 hbase-site.xml에 다음 프로퍼티를 설정해 HBase 데몬이 KeyStore 파일을 뒷받침하는 키 제공자를 사용하거나 클러스터 마스터 키를 검색하도록 구성하세요. 아래 예시에서 ****를 비밀번호로 바꾸세요.

<property>
  <name>hbase.crypto.keyprovider</name>
  <value>org.apache.hadoop.hbase.io.crypto.KeyStoreKeyProvider</value>
</property>
<property>
  <name>hbase.crypto.keyprovider.parameters</name>
  <value>jceks:///path/to/hbase/conf/hbase.jks?password=****</value>
</property>

기본적으로 HBase 서비스 계정 이름이 클러스터 마스터 키를 해석하는 데 사용돼요. 그러나 임의의 별칭(keytool 명령에서)으로 저장할 수 있어요. 그 경우 다음 프로퍼티를 사용한 별칭으로 설정하세요.

<property>
  <name>hbase.crypto.master.key.name</name>
  <value>my-alias</value>
</property>

투명한 암호화를 사용하려면 HFiles가 HFile v3를 사용하는지도 확인해야 해요. 이것은 HBase 1.0 이후의 기본 구성이에요. 이전 버전의 경우 hbase-site.xml 파일에 다음 프로퍼티를 설정하세요.

<property>
  <name>hfile.format.version</name>
  <value>3</value>
</property>

선택적으로 다른 암호 제공자를 사용할 수 있는데, Java Cryptography Encryption(JCE) 알고리즘 제공자 또는 사용자 지정 HBase 암호 구현이에요.

  • JCE:
    • 서명된 JCE 제공자 설치(128비트 키로 AES/CTR/NoPadding 모드 지원)
    • JCE 사이트 구성 파일 $JAVA_HOME/lib/security/java.security에 가장 높은 선호도로 추가.
    • hbase-site.xml에서 hbase.crypto.algorithm.aes.provider와 hbase.crypto.algorithm.rng.provider 옵션 업데이트.
  • 사용자 지정 HBase Cipher:
    • org.apache.hadoop.hbase.io.crypto.CipherProvider 구현.
    • 서버 클래스패스에 구현 추가.
    • hbase-site.xml에서 hbase.crypto.cipherprovider 업데이트.

WAL 암호화를 구성하세요.

모든 RegionServer의 hbase-site.xml에서 다음 프로퍼티를 설정해 WAL 암호화를 구성하세요. 이것들을 HMaster의 hbase-site.xml에도 포함할 수 있지만, HMaster는 WAL이 없어서 사용하지 않을 거예요.

<property>
  <name>hbase.regionserver.hlog.reader.impl</name>
  <value>org.apache.hadoop.hbase.regionserver.wal.SecureProtobufLogReader</value>
</property>
<property>
  <name>hbase.regionserver.hlog.writer.impl</name>
  <value>org.apache.hadoop.hbase.regionserver.wal.SecureProtobufLogWriter</value>
</property>
<property>
  <name>hbase.regionserver.wal.encryption</name>
  <value>true</value>
</property>

2.6.0부터 hbase.regionserver.hlog.reader.impl와 hbase.regionserver.hlog.writer.impl 구성은 제거됐어요. 더 이상 지정할 필요가 없어요. WAL 암호화를 활성화하려면 hbase.regionserver.wal.encryption을 true로 설정하기만 하면 충분해요.

(선택) 암호화 키 해시 알고리즘을 구성하세요.

HBASE-25181부터 기본 MD5 알고리즘 대신 사용자 지정 암호화 키 해시 알고리즘을 사용할 수 있어요. 이 해시는 복호화 중에 비밀 키를 검증하는 데 필요해요. MD5 알고리즘은 약한 것으로 간주되며 일부(예: FIPS 준수) 클러스터에서 사용할 수 없어요.

해시는 hbase.crypto.key.hash.algorithm 구성 옵션으로 설정돼요. "MD5", "SHA-384" 또는 "SHA-512" 같은 JDK MessageDigest 알고리즘으로 설정해야 해요. 하위 호환성을 위해 기본값은 "MD5"예요. FIPS 준수 클러스터에서 이 구성 파라미터의 예시:

<property>
  <name>hbase.crypto.key.hash.algorithm</name>
  <value>SHA-384</value>
</property>

hbase-site.xml 파일에 대한 권한을 구성하세요.

keystore 비밀번호가 hbase-site.xml에 저장되므로, 파일 소유권과 권한을 사용해 HBase 사용자만 hbase-site.xml 파일을 읽을 수 있도록 해야 해요.

클러스터를 재시작하세요.

새 구성 파일을 모든 노드에 배포하고 클러스터를 재시작하세요.

관리

관리 작업은 HBase Shell이나 Java API에서 수행할 수 있어요.

이 섹션의 Java API 예시는 소스 파일 hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsckEncryption.java에서 가져온 것이에요.

이 예시들도 그것이 가져온 소스 파일도 공용 HBase API의 일부가 아니며 설명 목적으로만 제공돼요. 사용 지침은 공식 API를 참고하세요.

Column Family에 암호화 활성화

column family에 암호화를 활성화하려면 HBase Shell이나 Java API를 사용할 수 있어요. 암호화를 활성화한 후 메이저 컴팩션을 트리거하세요. 메이저 컴팩션이 완료되면 컴팩션된 새 HFiles가 암호화될 거예요. 그러나 컴팩션 설정에 따라 메이저 컴팩션 중 모든 HFile이 다시 쓰여지지 않고 일부 옛 암호화되지 않은 HFiles가 남을 수 있어요. 또한 스냅샷은 불변이라는 점에 유의하세요. 그래서 암호화를 활성화하기 전에 찍은 스냅샷에는 여전히 암호화되지 않은 HFiles가 들어 있을 거예요.

데이터 키 회전

데이터 키를 회전하려면 먼저 column descriptor의 ColumnFamily 키를 변경한 다음 메이저 컴팩션을 트리거하세요. 컴팩션이 완료될 때까지 옛 HFiles는 옛 키로 여전히 읽을 수 있어요. 컴팩션 중 컴팩션된 HFiles는 새 데이터 키로 다시 암호화될 거예요. 그러나 컴팩션 설정에 따라 메이저 컴팩션 중 모든 HFile이 다시 쓰여지지 않고 옛 키로 암호화된 일부 옛 HFiles가 남을 수 있어요. 또한 스냅샷은 불변이라는 점에 유의하세요. 그래서 암호화 키 변경 전에 찍은 스냅샷에는 여전히 옛 키로 작성된 HFiles가 들어 있을 거예요.

랜덤 데이터 키 사용과 키 지정 사이 전환

column family가 특정 키를 사용하도록 구성했고 그 column family에 대해 랜덤 생성 키를 사용하는 기본 동작으로 돌아가려면, Java API로 HColumnDescriptor를 변경해 ENCRYPTION_KEY 키로 값이 전송되지 않게 하세요.

마스터 키 회전

마스터 키를 회전하려면 먼저 새 키를 생성하고 배포하세요. 그런 다음 KeyStore가 새 마스터 키를 포함하도록 업데이트하고 다른 별칭을 사용해 옛 마스터 키를 KeyStore에 유지하세요. 다음으로 hbase-site.xml 파일에서 옛 마스터 키로의 폴백을 구성하세요.

보안 활성화

hbase-2.x 이후 기본 'hbase.security.authorization'이 변경됐어요. hbase-2.x 이전에는 기본적으로 true였고, 이후 HBase 버전에서는 기본값이 false가 됐어요. 그래서 hbase authorization을 활성화하려면 hbase-site.xml에서 다음 프로퍼티를 구성해야 해요. HBASE-19483 참고.

<property>
  <name>hbase.security.authorization</name>
  <value>true</value>
</property>

더 알아보기 (Learn more)