데이터베이스 시스템 액세스 제어 측면

1. 배경 소개

정보 시스템 보안은 정보 시스템의 다양한 유형의 데이터 자원을 무단 액세스(보기, 추가, 수정, 삭제 포함)로부터 보호하고 데이터 무결성, 기밀성 및 가용성을 보장하는 것입니다. 현재 만물인터넷 개발 환경에서 정보 보안은 특히 중요합니다. 정보 보안의 중요한 부분인 접근 제어는 정보 시스템에 접근할 때 사용자의 신원을 인증할 수 있을 뿐만 아니라 정보에 대한 사용자의 접근 권한을 세밀하게 제어할 수 있습니다. 데이터베이스는 정보시스템의 기본 소프트웨어로서 데이터 저장을 담당하며 정보의 무결성, 기밀성, 가용성을 보장하기 위해 엄격한 접근 통제가 필요합니다.

다음은 내용의 일부를 발췌한 것입니다. 동영상을 클릭하시면 전체 버전을 보실 수 있습니다.

2. 접근 제어 모델 소개

접근통제 핵심 기능 및 요소

액세스 제어의 핵심 기능: 신원 인증 및 리소스 액세스 제어는 다음 네 가지 측면으로 구현됩니다. 합법적인 주체가 보호되는 시스템에 들어가도록 허용하고, 불법적인 주체가 보호되는 시스템에 액세스하도록 허용합니다. 접근은 합법적인 주체가 보호된 자원에 무단으로 접근하는 것을 금지합니다.

액세스 제어의 세 가지 요소는 주체, 개체 및 제어 정책입니다.

  • 주체, 시스템 사용자, 프로세스 또는 장치 등이 될 수 있는 리소스에 대한 액세스를 요청하는 엔터티입니다.
  • 액세스되는 리소스 엔터티인 개체는 파일 또는 데이터베이스 개체 등일 수 있습니다.
  • 제어 전략은 읽거나 쓰거나 실행할 수 있는 속성의 모음입니다.

신원인증

1. 비밀번호 기반 신원 인증은 신원 인증을 위해 사용자 이름과 비밀번호를 사용합니다.

2. 인증서 기반 신원 인증은 신원 인증을 위해 서명된 인증서를 사용합니다. 가장 일반적으로 사용되는 것은 TLS(Transport Layer Security, Transport Layer Security Protocol) 인증서입니다. 이 방법을 사용하면 인증서의 적법성 여부를 확인할 수 있을 뿐만 아니라 인증서와 시스템을 결합한 정보도 확인할 수 있다. 인증서의 적법성 확인에는 일반적으로 인증서의 유효성(인증서가 유효 기간 내에 있음)과 신뢰성(인증서 체인을 신뢰할 수 있음)에 대한 확인이 필요합니다. 시스템에 결합되는 정보는 일반적으로 Common Name이며 시스템 사용자의 정보와 관련되어 있습니다.

3. 제3자 인증센터 기반 신원인증 업무가 복잡하거나 하위시스템이 많은 정보시스템에서는 신원인증을 위해 통합된 인증센터를 이용하는 것이 필요하다. 일반적으로 사용되는 통합 ID 인증 아키텍처에는 LDAP, Radius, GSSAPI 등이 포함됩니다. KerberosV5, NTLM 및 SPNEGO와 같은 GSSAPI의 특정 구현이 많이 있습니다.

4. 생체 기반 신원 인증은 지문, 음성, 얼굴 인식, 홍채, 필기, 손 모양, 손바닥 지문 등 각 사용자의 고유한 생체 특성을 기반으로 합니다.

5. 하드웨어 장치 기반 신원 인증은 ID 카드, IC 카드 등 신원에 바인딩된 하드웨어 장치를 사용합니다.

6. OTP(One-Time-Password)는 본인 인증 과정에서 한 번만 사용되는 비밀번호입니다. 비밀번호를 사용하면 즉시 비밀번호가 무효화되어 다시 사용할 수 없습니다. OTP는 일반적으로 독립적으로 사용되지 않으며 신원 인증의 보안을 강화하기 위해 다른 인증 방법과 결합하고 2FA 또는 MFA 시나리오에서 사용되어야 합니다.

7. HBA(호스트 기반 인증) 기반 신원 인증 구성은 지정된 액세스 유형, 지정된 액세스 자원, 지정된 소스, 지정된 사용자의 신원 인증 방법 및 인증 매개변수를 구성하여 신원 인증 방법을 유연하게 구성합니다.

3. 리소스 접근 제어

접근통제 모델 개발 이력

정보 보안 정보화의 발전에 따라 접근통제 모델도 끊임없이 진화하고 있습니다. 초기에는 MAC(Mandatory Access Control, 필수 액세스 제어) 및 DAC(임의 액세스 제어, 임의 액세스 제어)가 있었고 이후에는 IBAC(Identity-Based Access Control, ID 기반 액세스 제어) 및 ACL(Access Control Lists, 액세스)이 있었습니다. 제어 목록)이 나타납니다).

정보시스템의 발달과 함께 널리 알려진 RBAC(Role-Based Access Control, 역할 기반 접근 제어)가 등장했고, 이를 기반으로 ABAC(속성 기반 접근 제어, 속성 기반 접근 제어)가 개발되었습니다. 일부 분야, 특히 데이터베이스 분야에서는 LBAC(Label-Based Access Control)가 개발되어 사용되고 있습니다.

액세스 제어 모델 소개

1. MAC MAC, 필수 액세스 제어. MAC의 필수 측면은 권한이 전담 관리자에 의해 관리된다는 것입니다. 상대적으로 보안 요구 사항이 높은 기밀 분야에서 MAC는 MLS(다단계 보안, 다단계 보안)를 중심으로 액세스 제어 모델을 구축했습니다. MLS는 원래 중앙을 향한 더 높은 수준의 보안을 갖춘 여러 계층의 액세스 제어 기능을 갖춘 동심원으로 고안되었습니다.

2. DAC DAC, 자율 액세스 제어. DAC의 자율성은 사용자가 자신의 희망에 따라 자신의 리소스를 다른 사용자와 선택적으로 공유할 수 있다는 사실에 반영됩니다.

3. ACL/IBAC ACL, 액세스 제어 목록. ACL은 일반적으로 리소스(예: 파일, 데이터베이스 레코드 또는 네트워크 리소스)와 직접 연결되어 액세스 권한과 액세스 권한(예: 읽기, 쓰기, 실행 등)이 있는 사용자를 나열하는 데이터 구조입니다. . ACL은 일반적으로 일련의 규칙(즉, ACL 항목)으로 구성됩니다. 각 ACL 항목은 특정 유형의 액세스 요청 허용 또는 거부를 포함한 액세스 제어 정책을 정의합니다.

IBAC, ID 기반 액세스 제어. IBAC는 사용자에게 자신의 ID(예: 사용자 이름 또는 사용자 ID)를 기반으로 리소스에 액세스할 수 있는 권한을 부여합니다. 액세스 권한을 개인의 신원과 직접 연결하는 것은 가장 직관적인 액세스 제어 방법 중 하나입니다. IBAC는 사용자 ID의 역할을 더욱 강조하고 ID 정보를 통해 접근 권한을 통제합니다. IBAC 모델은 사용자의 ID 정보를 리소스의 액세스 권한과 연결하여 사용자와 권한 간의 연결을 실현합니다. IBAC의 핵심은 ACL을 사용하여 어떤 사용자가 어떤 리소스에 액세스할 수 있는지 정의하는 것입니다.

4. RBAC RBAC, 역할 기반 액세스 제어입니다. RBAC는 현재 정보 시스템에서 가장 널리 사용되는 액세스 제어 모델입니다. RBAC의 핵심 개념은 권한이 역할과 연관되어 있고 사용자가 적절한 역할에 할당된다는 것입니다. 역할은 한쪽은 사용자 컬렉션이고 다른 쪽은 권한 컬렉션입니다. 이는 사용자 컬렉션과 권한 컬렉션을 결합하는 중개자 역할을 합니다. 오픈 소스 분야에서 RBAC의 유명한 오픈 소스 프레임워크로는 Spring Security 및 Apache Shiro가 있습니다.

실제로 RBAC는 다양한 애플리케이션 시나리오를 기반으로 4가지 참조 모델을 점진적으로 개발했습니다. • RBAC0: 기본 모델, RBAC를 지원한다고 주장하는 모든 시스템에 대한 최소 요구 사항 • RBAC1: RBAC0을 기반으로 하는 고급 모델, 역할 계층 기능 추가. 역할은 역할의 구성원이 될 수도 있고 상위로부터 권한을 상속받을 수도 있습니다. • RBAC2: RBAC0을 기반으로 하는 고급 모델은 사용자가 너무 많은 권한을 가지고 있어 발생하는 이해 상충을 방지하기 위해 업무 분리 기능을 추가합니다. 일반적인 업무 분리에는 정적 상호 배타적 역할, 런타임 상호 배타적 역할, 카디널리티 제약(총 역할 수), 전제 조건 제약 등이 포함됩니다. • RBAC3: RBAC0을 기반으로 하는 고급 모델은 RBAC1과 RBAC2의 장점을 결합합니다.

5. ABAC ABAC, 속성 기반 액세스 제어입니다. ABAC는 관련 엔터티의 속성을 승인의 기초로 사용하고, 속성 중 하나 또는 그룹이 특정 조건을 만족하는지 여부를 동적으로 계산하여 승인 판단을 내립니다.

ABAC의 액세스 제어 정책: u 속성을 가진 사용자는 c 속성 조건에서 d 객체 속성을 가진 리소스에 대해 o 속성을 가진 작업을 수행하는 것이 허용/금지됩니다(u, c, d, o는 임의의 예입니다). 따라서 ABAC의 핵심은 4가지 유형의 개체 속성입니다. 사용자 속성, 사용자가 소유한 나이, 부서, 직급 ​​등의 속성 환경 속성, 현재 시간, 허용 시간 등 접근 제어의 환경 조건 요소; 액세스 및 액세스가 허용된 하위 클래스 리소스 속성, 파일 유형, 데이터 민감도 등과 같은 리소스가 소유한 속성, 읽기, 쓰기, 실행 등과 같은 허용된 작업 유형

ABAC는 매우 유연한 권한 제어를 달성할 수 있으며 이론적으로 거의 모든 유형의 액세스 제어 요구를 충족할 수 있습니다.

6. LBAC LBAC, 레이블 기반 액세스 제어입니다. LBAC에서는 사용자와 데이터에 레이블이 할당되고 레이블을 기준으로 비교하여 사용자가 데이터에 액세스할 수 있는지 여부를 결정합니다. 사용자, 데이터 및 태그 간의 관계는 다음 다이어그램으로 설명할 수 있습니다. 데이터 레이블: 데이터 행의 민감도를 지정합니다. 사용자 레이블: 사용자에게 적절한 권한을 제공합니다. 사용자와 데이터 간의 액세스 조정은 사용자 레이블에 따라 다릅니다.

4. 접근통제에 관한 데이터베이스 표준 요구사항

"GB/T 20273-2019 정보 보안 기술 - 데이터베이스 관리 시스템에 대한 보안 기술 요구 사항", 액세스 제어 요구 사항에는 주로 세 가지 주요 기능 범주의 27개 기능 구성 요소가 포함됩니다.

사용자 데이터 보호

식별 및 식별

보안 관리

5. KaiwuDB 접근 제어

KaiwuDB 액세스 제어에는 신원 인증과 액세스 제어라는 두 부분도 포함됩니다.

KaiwuDB 신원 인증

1. 비밀번호 기반 신원 인증 KaiwuDB는 비밀번호 기반 신원 인증을 지원합니다. 사용자 비밀번호 보안 조치:

  • 비밀번호 저장 암호화 방식(국제알고리즘 및 상용비밀알고리즘)
  • 비밀번호에는 사용자 이름과 그 역순이 포함될 수 없습니다.
  • 비밀번호 최소 길이 제한
  • 최대 비밀번호 길이 제한
  • 대문자 개수
  • 소문자 개수
  • 자릿수
  • 특수 기호 숫자
  • 포함되는 문자 범주 수 제한(대문자, 소문자, 숫자, 특수 기호)

2. 인증서 기반 신원 인증 KaiwuDB는 TLS 인증서 기반 신원 인증을 지원합니다. 인증서의 만료 시간과 인증서 체인을 확인할 수 있으며, 인증서의 일반 이름과 데이터베이스 시스템의 사용자 이름을 확인할 수 있습니다.

3. 제3자 통합 인증 기반 신원 인증 KaiwuDB는 제3자 통합 인증 기반 신원 인증을 지원하며, 구체적인 구현은 Kerberos V5 통합 인증입니다.

4. 2FAK aiwuDB는 TLS 인증서와 비밀번호를 기반으로 한 2FA를 지원합니다.

5. HBAK aiwuDB는 지정된 액세스 유형, 지정된 액세스 리소스, 지정된 소스, 지정된 사용자 신원 인증 방법 및 해당 인증 매개변수 구성을 지원하므로 신원 인증 방법을 유연하게 구성할 수 있습니다.

KaiwuDB 접근 제어

1. 접근 제어 목록 KaiwuDB는 사용자 및 데이터베이스 객체에 대한 접근 제어 권한을 직접 관리할 수 있는 접근 제어 목록을 지원합니다.

2. RBACKaiwuDB는 RBAC1 모델을 지원하고 역할 기반 액세스 제어를 수행할 수 있으며 역할 계층 관리 및 권한 상속을 지원합니다.

3. LBACKaiwuDB는 LBAC 접근 제어를 지원하며 태그 기반의 접근 제어를 수행할 수 있습니다. 레이블은 현재 사용자에게 허용된 액세스 수준과 데이터의 민감도 수준을 표시하는 수준 구성 요소를 지원합니다. 사용자는 허용된 액세스 수준보다 낮은 민감도 수준의 데이터에만 액세스할 수 있습니다.

4. ABACKaiwuDB는 ABAC를 지원하며 속성을 기반으로 접근 제어를 수행할 수 있습니다. ABAC에서 지원하는 사용자 속성은 다음과 같습니다.

  • CREATEDB/NOCREATEDB: 사용자의 CREATE DATABASE 작업을 허용/비활성화합니다.
  • CREATEROLE/NOCREATEROLE: 사용자의 CREATE ROLE 및 CREATE USER 작업을 허용/비활성화합니다.
  • LOGIN/NOLOGIN: 사용자 로그인을 허용/비활성화합니다.
  • FAILED_LOGIN_ATTEMPTS: 사용자에게 허용되는 최대 로그인 시도 실패 횟수입니다. 연결 제한: 사용자에게 허용되는 최대 동시 로그인 연결 수입니다.
  • VALID UNTIL: 사용자의 비밀번호 유효 기간입니다. 유효기간 이후에는 로그인이 불가능합니다.

6. KaiwuDB 접근제어 향후 계획

1. 본인인증 향후 계획

향후 신원 인증 계획에서는 주로 다음 기능을 구현할 계획입니다.

  • 2FA/MFA: 사용자 비밀번호 및 인증서의 2FA 외에도 인증코드, OTP 추가 등 더 많은 2FA 및 MFA 신원 인증을 지원합니다.
  • 3자 통합 인증 및 신원 인증: Kerberos V5 외에도 LDAP, Radius 등 3자 통합 인증을 지원합니다.

2. 접근통제 향후 계획

향후 액세스 제어 계획에서는 주로 다음 기능을 구현할 계획입니다. 보안 역할 제한:

  • 세 권한 분리 또는 더 많은 역할과 책임 분리와 같은 직무 분리 기능을 포함하여 RBAC3 모델을 지원합니다.
  • LBAC 기능 강화 : 현재의 Level 컴포넌트부터 Level, Compartment, Group 컴포넌트를 포함한 LBAC까지, 이를 기반으로 Column 레벨, Row 레벨 등 보다 세분화된 접근 제어를 구현할 수 있습니다.
오픈 소스 산업용 소프트웨어를 포기하기로 결정했습니다 . 주요 이벤트 - OGG 1.0 출시, Huawei가 모든 소스 코드를 제공했습니다. Google Python Foundation 팀이 "코드 똥산"에 의해 해고되었습니다 . ". Fedora Linux 40이 정식 출시되었습니다. 유명 게임 회사가 출시했습니다. 새로운 규정: 직원의 결혼 선물은 100,000위안을 초과할 수 없습니다. China Unicom은 세계 최초로 오픈 소스 모델의 Llama3 8B 중국어 버전을 출시했습니다. Pinduoduo는 보상금을 선고 받았습니다 . 불공정 경쟁에 500만 위안 국내 클라우드 입력 방식 - 화웨이만 클라우드 데이터 업로드 보안 문제 없음
{{o.이름}}
{{이름}}

추천

출처my.oschina.net/u/5148943/blog/11048561