[정처기실기] 3. 물리 데이터베이스 설계
지난 시간에는 목표 DBMS를 위한 논리 데이터 설계에서 이상현상(삽입, 삭제, 갱신)을 제거하기 위해 정규화하는 과정에 대해 학습하였습니다. 데이터 베이스 설계는 정보처리기사 시험에 매우 자주 출제 되므로 꼭 암기하고 지나가셔야합니다.
이번 시간에는 논리 데이터 설계 후에 진행하는특정 DBMS를 위한 물리 데이터 설계에 대한 내용을 공부할 것입니다. 여기서 중요한 개념은 반정규화입니다. 앞서 배운 정규화를 깨는 것인데, 이는 성능을 고려하기 때문입니다.
목차
물리 데이터 설계란?
실제로 데이터 저장되는 저장매체에 대한 설계를 진행하는 과정입니다.
논리적 데이터 모델을 실제로 데이터베이스 관리 시스템(DBMS)이나 저장 장치에 구현하는 과정입니다.
즉, 물리 데이터 설계는 논리적 데이터 모델에 기반하여 실제로 데이터를 저장하고 접근할 수 있는 물리적인 구조를 결정하는 단계입니다.
물리 데이터 설계 과정
과정은 크게 중요하지 않아 패스 하셔도 좋습니다.
- 저장 요구사항 분석: 시스템 요구사항과 성능 목표를 고려하여 저장 요구사항을 분석합니다.
- 데이터베이스 객체 식별: 논리적 데이터 모델을 기반으로 테이블, 인덱스, 파티션 등의 물리적 객체를 식별합니다.
- 저장 구조 설계: 데이터의 저장 및 접근 방법을 결정하고 파일 구조, 인덱스 유형, 클러스터링 등을 설계합니다.
- 파티셔닝 및 분할: 대용량 데이터베이스의 경우 데이터를 파티션으로 분할하거나 분할된 데이터를 별도의 테이블로 분리하여 처리합니다.
- 인덱스 및 클러스터링 설계: 필요한 경우 인덱스를 설계하고 데이터를 클러스터링하여 성능을 최적화합니다.
- 저장 장치 및 용량 계획: 데이터베이스가 저장될 물리적 저장 장치 및 용량을 결정합니다.
- 보안 및 암호화: 데이터를 보호하기 위해 보안 정책과 암호화 방법을 결정하고 구현합니다.
- 성능 튜닝: 쿼리 최적화, 인덱스 튜닝 등을 통해 데이터베이스의 성능을 최적화합니다
논리 데이터를 물리 데이터로 변환화는 과정
- 테이블 설계: 논리 데이터 모델에서 정의한 개체(Entities)와 관계(Relationships)를 기반으로 데이터베이스 테이블을 설계합니다. 각 개체는 테이블로 변환되고, 관계는 외래 키(Foreign Key)로 구현됩니다.
- 속성 및 데이터 유형 정의: 각 테이블에 대한 속성(Attribute)을 정의하고, 해당 속성에 대한 데이터 유형을 결정합니다. 이는 논리 데이터 모델에서 속성에 부여된 도메인과 관련이 있습니다.
- 정규화 적용: 필요한 경우 논리 데이터 모델을 정규화하여 데이터 중복을 최소화하고 데이터 일관성을 유지합니다. 정규화된 테이블은 물리 데이터 모델에도 반영되어야 합니다.
- 인덱스 및 제약 조건 정의: 물리 데이터 모델에는 적절한 인덱스(Index) 및 제약 조건(Constraints)을 정의하여 데이터베이스의 성능을 향상시키고 데이터 무결성을 유지합니다.
- 데이터베이스 특성 및 세부 설정 결정: 데이터베이스 관리 시스템(DBMS)에 따라 특정한 설정이나 세부적인 구성이 필요할 수 있습니다. 이러한 설정은 데이터베이스의 운영 및 성능에 영향을 미치므로 신중하게 결정되어야 합니다.
- 물리적 저장 구조 설계: 테이블과 인덱스의 물리적 저장 구조를 결정합니다. 이는 데이터베이스 파일의 배치, 데이터 파일 및 로그 파일의 크기 및 위치 등을 포함합니다.
- 시퀀스 및 자동 증가 열 정의: 필요한 경우 일련 번호를 생성하기 위해 시퀀스(Sequence)나 자동 증가 열(Auto-increment Column)을 정의합니다.
- 클러스터링 및 파티셔닝: 대용량 데이터베이스의 경우 클러스터링(Clustering)이나 파티셔닝(Partitioning)을 사용하여 데이터를 효율적으로 관리하고 성능을 최적화합니다.
- 데이터베이스 객체 생성: 정의된 물리적 구조에 따라 데이터베이스 객체를 생성합니다. 이는 SQL 문을 사용하여 테이블, 인덱스, 제약 조건 등을 생성하는 단계를 포함합니다.
- 데이터 이관 및 마이그레이션: 마지막으로, 논리 데이터 모델에서 실제 물리 데이터베이스로 데이터를 이관하고, 필요한 경우 데이터베이스 마이그레이션 프로세스를 수행하여 논리적인 데이터와 일치하도록 보장합니다.
설계 특징
특징은 크게 중요하지 않아 패스 하셔도 좋습니다.
- 저장 구조에 밀접한 관련: 물리 데이터 설계는 데이터의 실제 저장 구조에 집중하여 이를 최적화합니다.
- 성능 중심: 물리 데이터 설계는 주로 데이터베이스의 성능을 향상시키는데 중점을 둡니다.
- 하드웨어 의존적: 물리 데이터 설계는 데이터베이스를 실행하는 하드웨어 환경에 맞추어 설계됩니다.
고려사항
고려사항은 크게 중요하지 않아 패스 하셔도 좋습니다. 물리 설계를 하는 이유이기도 하므로 물리설계를 서술하라는 문제를 위해 키워드는 보고 지나가셔도 좋습니다.
- 성능: 데이터베이스의 응답 시간과 처리량을 최적화하기 위해 고려되어야 합니다.
- 가용성: 데이터베이스 시스템의 가용성을 보장하기 위해 백업, 복구 및 장애 조치 기능이 고려되어야 합니다.
- 보안: 데이터의 보안 및 접근 제어가 필요한 경우 이를 고려하여 설계해야 합니다.
- 확장성: 데이터베이스가 미래에 확장될 수 있도록 설계되어야 합니다.
- 용이성: 데이터베이스의 관리 및 유지보수를 위해 설계가 단순하고 유지보수가 용이해야 합니다.
- 비용: 하드웨어, 소프트웨어 및 유지보수 비용을 고려하여 설계되어야 합니다
반정규화 (Denormalization) 란?
반정규화(Denormalization)는 데이터베이스 설계에서 정규화된 상태의 테이블을 일부러 중복이나 반복을 포함하도록 변경하는 프로세스를 말합니다.
일반적으로 성능 향상이나 쿼리의 간소화를 목적으로 합니다.
정규화는 데이터 중복을 최소화하여 데이터 일관성과 무결성을 유지하는 반면, 반정규화는 성능을 향상시키거나 쿼리의 복잡도를 줄이는 데 중점을 둡니다.
모범 답안 : 데이터 베이스 설계에서 정규화를 거친 후, 성능 향상이나 개발 및 운영의 편의성을 위해 의도적으로 중복을 허용하거나 데이터를 재구성하는 기법
반정규화의 특징(고려사항)
- 성능 향상: 주요한 목적 중 하나는 데이터베이스의 응답 시간을 개선하기 위해 정규화된 테이블을 조인하는 것을 줄여 성능을 향상시키는 것입니다.
- 쿼리의 간소화: 반정규화는 쿼리를 더 간단하게 만들 수 있습니다. 조인 연산이 줄어들기 때문에 쿼리의 복잡성이 감소하고 쿼리 작성이 더 쉬워질 수 있습니다.
- 일부 속도 저하 : 삽입, 삭제, 수정 작업은 느려질 수 있습니다.
- 데이터 중복 증가: 중복된 데이터가 증가하므로 데이터의 일관성과 무결성에 주의해야 합니다.
- 중복된 데이터를 일관되게 유지하기 위한 메커니즘이 필요합니다.
- 이상현상이 생길 수 있다는 뜻입니다.
- 유지보수 복잡성 증가: 데이터의 중복성으로 인해 데이터의 변경이 더 복잡해질 수 있습니다
- 데이터의 변경이 발생할 때마다 모든 중복된 사본을 업데이트해야 합니다.
- 저장 공간 증가: 중복된 데이터가 증가하면 저장 공간도 증가할 수 있습니다.
- 데이터베이스 용량을 적절히 예측하고 관리해야 합니다.
- 데이터 일관성 유지: 중복된 데이터의 변경은 데이터 일관성을 유지하기 어렵게 만들 수 있으므로, 이를 위한 적절한 관리 방안이 필요합니다.
- 적절한 캐시 및 인덱싱: 데이터 중복이 증가하면 캐시와 인덱스 관리도 더 복잡해집니다. 따라서 적절한 캐시 및 인덱싱 전략이 필요합니다.
반정규화의 적용 순서
- 반정규화 대상 조사
- 먼저, 데이터베이스의 성능 문제 또는 쿼리의 복잡성을 해결하기 위해 반정규화가 필요한 테이블을 조사합니다.
- 정규화된 테이블 중에서 자주 사용되는 테이블이나 조인 연산이 많은 테이블을 대상으로 고려될 수 있습니다.
- 다른 방법으로 유도
- 반정규화를 적용하기 전에 다른 방법으로 성능 향상을 시도해볼 수 있습니다. 인덱싱, 클러스터링, 파티셔닝, 쿼리 최적화, 캐시 사용 등의 방법을 고려합니다.
- 반정규화는 성능 최적화의 마지막 수단으로 고려되어야 합니다.
- 반정규화 수행
- 반정규화를 실제로 수행합니다. 이는 정규화된 테이블을 중복이나 반복을 포함하도록 변경하는 것을 의미합니다.
- 일반적으로 중복된 열을 추가하거나 여러 테이블을 병합하여 새로운 테이블을 생성하는 것이 포함될 수 있습니다.
- 쿼리의 성능 향상을 위해 테이블 구조를 변경하고, 쿼리의 복잡성을 줄이기 위해 조인 연산을 최소화하는 것이 목표입니다.
반정규화 유형
- 데이터 분할
- 수평 분할(Horizontal Partitioning): 테이블의 행을 여러 개의 테이블로 나누는 것입니다. 이 방법은 대용량 테이블을 작은 단위로 분할하여 데이터베이스의 성능을 향상시킵니다.
- 수직 분할(Vertical Partitioning): 테이블의 열을 분할하여 여러 개의 테이블로 나누는 것입니다. 이 방법은 자주 사용되는 열을 따로 분리하여 성능을 향상시킵니다.
- 데이터 중복
- 통계 테이블 추가: 주로 집계 및 통계 정보를 제공하기 위해 데이터의 일부를 중복하여 저장하는 테이블을 추가하는 것입니다.
- 진행 테이블 추가: 특정 프로세스 또는 작업의 진행 상태를 추적하기 위해 중복된 정보를 저장하는 테이블을 추가하는 것입니다.
- 컬럼 기반 분할
- 조회 빈도 기반 분할: 자주 조회되는 열을 따로 분리하여 접근 빈도가 높은 데이터에 대한 성능을 향상시킵니다.
- 크기 기반 분할: 특정 열의 크기가 큰 경우 해당 열을 별도의 테이블로 분할하여 성능을 최적화합니다.
- 컬럼 중복
- 중복 컬럼 추가: 특정 열을 별도의 테이블에 중복하여 저장하는 것입니다. 이를 통해 데이터 조회 및 처리 성능을 향상시킬 수 있습니다.
- 파생 컬럼 추가: 기존 열을 기반으로 새로운 파생된 열을 추가하여 중복된 정보를 저장하는 것입니다. 이를 통해 쿼리의 간소화 및 성능 향상을 이룰 수 있습니다.
테이블 저장 사이징
데이터베이스 용량 분석은 데이터베이스 관리자가 데이터베이스의 크기를 이해하고 관리하는데 중요한 역할을 합니다. 테이블 사이징, 테이블 용량 계산 및 인덱스 용량 계산은 이러한 분석의 일부입니다.
데이터베이스 용량 분석
- 자원 관리: 데이터베이스 용량을 분석하여 서버 자원을 효율적으로 관리하고 할당할 수 있습니다.
- 성능 최적화: 데이터베이스 용량 분석을 통해 특정 테이블 또는 인덱스의 크기를 파악하고 성능을 최적화할 수 있습니다.
- 비용 관리: 용량 분석을 통해 데이터베이스 서버의 용량 요구를 정확히 파악하여 비용을 관리하고 최적화할 수 있습니다.
테이블 사이징
테이블 저장 사이징은 테이블의 데이터 및 인덱스에 필요한 저장 공간을 계산하는 과정입니다.
초기 크기 계산
- 데이터 크기 분석: 각 테이블의 열에 저장되는 데이터의 크기를 분석합니다.
- 레코드 수 분석: 테이블에 저장될 예상 레코드 수를 고려하여 데이터의 총량을 추정합니다.
- 인덱스 크기 추정: 테이블에 생성된 인덱스의 크기를 추정합니다.
확장 크기 계산
- 증가율 고려: 데이터베이스의 데이터 증가율을 고려하여 미래의 데이터 증가를 예측합니다.
- 예비 용량 할당: 예상되는 데이터 증가에 대비하여 충분한 용량을 할당합니다.
테이블 용량 계산
- 테이블 용량 계산: 테이블의 각 열에 저장되는 데이터의 크기와 예상 레코드 수를 고려하여 테이블의 저장 공간을 계산합니다.
- 인덱스 용량 계산: 인덱스 키의 크기와 예상 레코드 수를 고려하여 인덱스의 저장 공간을 계산합니다.
인덱스 용량 계산
- 덱스 키의 크기 계산
- 인덱스에 사용되는 각 키의 크기를 파악합니다. 예를 들어, INT, VARCHAR 등의 데이터 유형에 따라 키의 크기가 다릅니다.
- 예상 레코드 수 파악
- 해당 인덱스가 지원할 예상 레코드 수를 파악합니다. 이는 인덱스가 적용된 열의 고유한 값의 수에 의해 결정됩니다.
- 인덱스 블록 크기 고려
- 데이터베이스 시스템의 블록 크기를 고려하여 각 인덱스 레코드의 크기를 계산합니다. 이는 데이터베이스 시스템의 구성에 따라 다를 수 있습니다.
- 인덱스의 전체 크기 계산
- 각 인덱스 레코드의 크기와 예상 레코드 수를 곱하여 해당 인덱스의 전체 크기를 계산합니다.
데이터 베이스 이중화
고가용성(HA, High Availability)를 위한 정보 시스템의 지속적인 정상 운영을 목표로 함.
장애에 대비하여 동일한 데이터베이스를 중복하여 관리하는 방식
데이터베이스 이중화는 데이터베이스 시스템의 가용성과 내결함성을 향상시키기 위해 사용되는 중요한 기술입니다.
일반적으로 이중화는 두 개 이상의 데이터베이스 서버를 사용하여 동일한 데이터를 복제하고 동기화하는 방식으로 구성됩니다.
이를 통해 하나의 데이터베이스 서버가 다운되더라도 시스템이 중단되지 않고 작동할 수 있습니다.
데이터베이스 이중화의 목적
- 고가용성 제공
- 데이터베이스 이중화는 시스템의 가용성을 향상시켜 중단 시간을 최소화합니다.
- 이는 데이터베이스 서버의 장애가 발생했을 때 시스템이 계속 작동할 수 있도록 보장합니다.
- 내결함성 보장
- 이중화된 데이터베이스 시스템은 데이터를 복제하여 여러 개의 서버에 저장합니다.
- 이를 통해 하나의 서버에 장애가 발생하더라도 시스템이 계속 작동할 수 있습니다.
- 데이터 손실 최소화
- 데이터베이스 이중화는 데이터를 여러 개의 서버에 복제하므로 데이터 손실을 최소화할 수 있습니다.
- 데이터를 복제하는 과정에서 하나의 서버에 장애가 발생해도 다른 서버에 데이터가 안전하게 보관됩니다.
- 성능 향상
- 데이터베이스 이중화를 통해 데이터베이스 서버의 부하를 분산할 수 있습니다.
- 이는 시스템의 처리량과 응답 속도를 향상시킬 수 있습니다.
- 비즈니스 연속성 유지
- 데이터베이스 이중화는 비즈니스 연속성을 유지하는 데 중요한 역할을 합니다.
- 장애 발생 시에도 시스템이 계속 작동하므로 비즈니스 프로세스 및 서비스의 연속성을 보장할 수 있습니다.
데이터 베이스 이중화 분류
분류 | 설명 |
Eager 기법 | 트랜잭션 발생 시 즉시 모든 이중화 서버에 변경 사항 반영 그때 그때 반영 이중화된 데이터베이스 서버가 동시에 데이터를 복제하는 방법입니다. 쓰기 작업이 발생하면 이를 즉시 모든 복제 서버에 적용하고 확인합니다. 이를 통해 데이터의 일관성을 유지하고 데이터 손실을 최소화합니다. |
Lazy 기법 | 트랜잭션 완료 후 변경 사항을 트랜잭션 형태로 각 노드 전달 작업이 끝나고 나서 반영 이중화된 데이터베이스 서버가 데이터를 복제하는 것을 지연시키는 방법입니다. 쓰기 작업이 발생하면 주 서버에만 적용되고, 다른 서버에는 일정 시간이 지난 후에 복제됩니다. 이는 데이터 복제의 지연을 초래할 수 있습니다. |
데이터 베이스 이중화의 종류
Active-Active | WAS에 구성하는 것이 보통 모든 다중화된 장비가 활성화 된다. 모든 데이터베이스 서버가 동시에 활성화되어 트래픽을 분산하는 방식입니다. 모든 서버가 동일한 데이터를 동시에 처리하므로 시스템의 가용성을 향상시키고 처리량을 분산할 수 있습니다. |
Active-Standby | 주 서버(Active)와 백업 서버(Standby)로 구성되어 있습니다. 주 서버가 장애 발생 시에는 백업 서버가 활성화되어 서비스를 대신 제공합니다. 일반적으로 주 서버에 장애가 발생할 때까지 백업 서버는 대기 모드에 있습니다. hot stand by, warm standby, cold standby |
- 주 서버 (Active
- 실제로 사용자 요청에 응답하는 서버입니다.
- 데이터베이스에 대한 모든 쓰기 작업을 처리합니다.
- 주 서버는 시스템의 주요 작업을 처리하는데 사용되며, 사용자의 요청에 따라 데이터를 읽고 쓰는 등의 작업을 수행합니다.
- 백업 서버 (Standby)
- 주 서버의 백업이며, 주 서버에 대비하여 대기 모드에 있습니다.
- 주 서버에 장애가 발생하면 백업 서버가 활성화되어 서비스를 대신 제공합니다.
- 백업 서버는 주 서버와 동일한 데이터를 유지하고 있어야 합니다. 주 서버의 변경 사항은 주기적으로 백업 서버에 복제됩니다.
데이터 베이스 백업
데이터베이스 백업은 데이터베이스의 정보를 안전하게 보호하기 위해 데이터를 복사하고 저장하는 과정입니다.
백업을 안하면, 기존 작업된 정보 및 저장된 정보가 모두 날아가된다는 것은 이미 충분히 아실 겁니다.
![](https://t1.daumcdn.net/keditor/emoticon/friends2/large/008.png)
이 개념은 이미 알고 계시기 때문에 Full Back up과 Incremental Back Up만 구분하시면 됩니다.
증분 백업은 풀백업 이후에 새로운 데이터만 백업하는 것입니다.
주요 데이터베이스 백업 목적
1) 데이터 손실 방지: 시스템 장애, 사용자 오류 또는 악의적인 공격으로 인한 데이터 손실을 방지합니다.
2) 비상 대비: 장애 발생 시에 데이터를 복구하고 시스템을 빠르게 복구하기 위한 대비책을 마련합니다.
3)법적 준수: 데이터 보존을 위한 규정에 따라 데이터를 보관하고 관리합니다.
주로 백업과 복원을 위해 진행합니다.
- 백업 (Backup)
- 백업은 데이터베이스의 정보를 안전한 장소에 복사하여 보관하는 과정을 말합니다.
- 전체 데이터베이스 백업 또는 특정 데이터베이스 객체(테이블, 인덱스 등)의 백업이 가능합니다.
- 주기적으로 스케줄링되어야 하며, 일반적으로 전체 백업과 추가적인 증분 백업이 함께 사용됩니다.
- 백업에는 전체 복사본을 저장하는 풀 백업(Full Backup), 변경된 부분만을 저장하는 증분 백업(Incremental Backup) 등이 있습니다.
- 복원 (Restore)
- 복원은 백업된 데이터를 사용하여 데이터베이스를 이전 상태로 되돌리는 과정을 말합니다.
- 시스템 장애나 데이터 손실 발생 시에 데이터를 복구하기 위해 사용됩니다.
- 백업된 데이터를 사용하여 데이터베이스를 복원하고, 필요한 경우 데이터베이스 시스템을 재구성합니다.
백업 방식
백업 방식 | 설명 |
전체 백업 (Full Backup) |
데이터베이스의 전체 내용을 한 번에 백업하는 방식입니다. 모든 데이터와 객체가 복사됩니다. |
증분 백업 (Incremental Backup) |
이전 전체 백업 이후 변경된 부분만을 백업하는 방식입니다. 초기 전체 백업 이후 변경된 데이터만을 추가하여 백업합니다. 시간 절약을 위해 첫 풀백을 제외하고 그날 그날 정보만을 백업하는 것 |
차등 백업 (Differential Backup) |
이전 전체 백업 이후 변경된 부분만을 백업하는 방식입니다. 증분 백업과 유사하지만 변경된 데이터의 누적된 차이만을 백업합니다. 첫 풀백업을 제외하고 계속 하위 내용을 누적 백업하는 것 |
실시간 백업 (Continuous Backup) |
데이터베이스의 변경 사항이 발생할 때마다 실시간으로 백업하는 방식입니다. 변경이 발생하면 즉시 해당 부분을 백업합니다. |
트랜잭션 로그 백업 (Transaction Log Backup) |
데이터베이스의 트랜잭션 로그를 주기적으로 백업하는 방식입니다. 데이터 변경 이력을 저장하고 복구에 사용됩니다. REDO 및 UNDO 작업을 통해 데이터베이스를 복원 |
합성 백업 (Synthetic Backup) |
전체 백업과 증분을 결합하여 데이터베이스의 일관된 이미지를 생성하는 방식입니다. 전체 백업과 증분/차등 백업을 조합합니다. |
복구 시간 목표/ 복구 시점 목표
지표 | 특징 |
RTO (Recovery Time Objective) |
- 시스템 또는 서비스가 중단되었을 때, 복구하는데 소요되는 시간을 나타냅니다. |
- 최대 허용 복구 시간을 나타내며, 시스템 복구 후 정상 운영으로 복귀하는 시간입니다. | |
- 업무 연속성 계획(BCP)에서 중요한 지표로 사용되며, 장애 발생 시에 시스템 복구에 소요되는 시간을 제한합니다. | |
서비스를 활용할 수 없는 시간에 대한 규정 | |
RPO (Recovery Point Objective) |
- 시스템 또는 서비스가 중단되었을 때, 복구 시점으로써 허용 가능한 데이터 손실의 최대 정도를 나타냅니다. |
- 최신 데이터로의 복구를 보장하는데 사용되며, 중단 직전에 생성된 마지막 백업으로 복구할 수 있는 시점을 결정합니다. | |
- 백업 주기 및 데이터 복구 전략을 결정할 때 중요한 요소로 사용되며, 데이터 손실을 최소화하는 목표를 설정합니다. |
데이터 베이스 암호화
데이터베이스 암호화는 데이터베이스 내에 저장된 데이터를 보호하기 위해 사용되는 기술적 접근 방법입니다.
이는 데이터를 암호화하여 민감한 정보가 노출되지 않도록 보호하고 데이터의 기밀성을 유지하는 데 사용됩니다.
데이터 베이스 암호화 필요성
- 데이터 보안 강화
- 암호화를 사용하면 데이터베이스 내에 저장된 민감한 정보를 보호할 수 있습니다.
- 무단 접근으로부터 데이터를 보호하여 중요한 정보가 유출되는 것을 방지할 수 있습니다.
- 규정 준수
- 많은 산업 분야에서는 개인정보 보호법, 금융 규정, 의료 기록 보안 등과 같은 규정 준수 요구 사항을 준수해야 합니다.
- 데이터베이스 암호화는 이러한 규정 준수를 준수하기 위한 필수 요구 사항 중 하나입니다.
- 데이터 손실 방지
- 데이터베이스 암호화를 사용하면 데이터가 노출되었을 때 발생할 수 있는 잠재적인 손실을 방지할 수 있습니다.
- 암호화된 데이터는 무단 액세스로부터 보호되며, 데이터 유출이 발생하더라도 암호화된 형식으로 저장되어 있어 데이터의 기밀성을 유지할 수 있습니다.
- 신뢰 구축
- 고객 및 이해 관계자들에게 데이터 보안에 대한 신뢰를 구축합니다.
- 데이터베이스 암호화를 사용하여 중요한 데이터를 안전하게 보호하는 것은 기업이 정보 보안에 신경을 쓴다는 메시지를 전달할 수 있습니다.
- 사내 보안 강화
- 데이터베이스 내의 암호화는 사내에서도 중요합니다.
- 내부자에 의한 데이터 유출 및 악의적인 행동으로부터 데이터를 보호하고, 직원들 간에도 민감한 정보에 대한 접근을 제한함으로써 데이터 보안을 강화할 수 있습니다.
데이터 베이스 암호화 방식
암호화 방식 | 설명 |
API 방식 | 데이터베이스 시스템의 API를 사용하여 암호화 및 복호화를 수행하는 방식입니다. 애플리케이션에서 API를 호출하여 데이터를 암호화하거나 복호화합니다. |
Plug-in 방식 | 데이터베이스 시스템에 특별한 암호화 플러그인을 설치하여 암호화 기능을 확장하는 방식입니다. 플러그인을 통해 데이터를 암호화하고 복호화합니다. |
TED 방식 | 암호화 모듈을 데이터베이스 엔진에 직접 통합하여 암호화 기능을 제공하는 방식입니다. 데이터베이스 엔진 내에서 데이터를 암호화하고 복호화합니다. |
파일 암호화 방식 | 데이터베이스 파일을 직접 암호화하는 방식으로, 파일 시스템 수준에서 데이터를 암호화합니다. 파일이 저장되거나 전송될 때 암호화되고 해독됩니다. |
하드웨어 방식 | 전용 하드웨어 모듈을 사용하여 데이터베이스의 암호화 및 복호화를 수행하는 방식입니다. 하드웨어 보안 모듈이 데이터 암호화를 처리합니다. |
데이터 베이스 암호화 국가정보원 권고사항
항목국가정보원 권고 | 내용 |
안전한 알고리즘 | 공인된 암호화 알고리즘 및 표준을 사용하여 데이터를 암호화하고 복호화해야 합니다. SEED, ARIA, SHA-256 |
암호키 관리 | 암호화 키를 안전하게 관리하고 저장하여 무단 액세스로부터 보호해야 합니다. |
데이터 암/복호화 | 데이터의 암호화 및 복호화 작업은 안전하게 수행되어야 하며, 적절한 권한과 절차를 준수해야 합니다. IPSec, SSL, SHTTP, TLS |
접근통제 | 데이터베이스에 액세스하는 사용자를 관리하고 제한하여 불법적인 액세스를 방지해야 합니다. |
암호통신 | 데이터베이스와의 통신이 암호화되어야 하며, 안전한 통신 프로토콜을 사용하여 데이터를 전송해야 합니다. |
식별 및 인증 | 사용자를 식별하고 인증하여 데이터베이스에 접근하는 사용자의 신원을 확인해야 합니다. |
보안 감사 | 데이터베이스 암호화 작업과 관련된 모든 활동을 감사하고 모니터링하여 보안 위협을 탐지하고 예방해야 합니다. |
보안 관리 | 데이터베이스 암호화에 대한 정책과 절차를 수립하고 이를 지속적으로 관리하여 데이터 보안 수준을 유지해야 합니다. |
'정보처리기사' 카테고리의 다른 글
5. 관계 데이터 모델 - 2과목 데이터 베이스 구축 (0) | 2024.04.01 |
---|---|
4. 데이터 베이스 물리속성 설계 - 2과목 데이터 베이스 구축 (0) | 2024.03.31 |
2. 논리데이터베이스 설계 - 2과목 데이터베이스 구축 (1) | 2024.03.31 |
1. 데이터 베이스 구축 - 2과목 데이터베이스 구축 (2) | 2024.03.30 |
22. 애플리케이션 패키징- 제품 소프트웨어 패키징 - 1과목 소프트웨어 구축 (0) | 2024.03.29 |
댓글