Netwrix 1Secure는 데이터와 아이덴티티 전반에 걸쳐 통합된 가시성을 제공합니다 - 14일간 무료로 전체 액세스가 가능합니다.무료 평가판 시작

리소스 센터블로그

데이터베이스에 절대 저장하면 안 되는 4가지

데이터베이스에 절대 저장하면 안 되는 4가지

Jan 13, 2022

데이터베이스는 주로 다양한 업무상 중요한 애플리케이션을 지원하는 데 사용됩니다. 여러 종류의 데이터를 저장할 수 있습니다. 하지만 데이터베이스에 절대 보관하면 안 되는 것들이 있습니다.

이러한 기본 데이터베이스 보안 기법은 데이터를 보호하는 데 도움이 됩니다:

보호되지 않은 인증 정보

아마도 너무나 당연한 이야기겠지만, 데이터베이스에 평문 비밀번호를 저장하는 것은 좋은 생각이 아닙니다.

해커가 이 표의 데이터에 접근하게 되면, 해당 해커는 모든 사용자의 모든 비밀번호 목록을 얻게 됩니다. 이러한 비밀번호는 평문으로 읽을 수 있는 텍스트 형태로 저장되어 있어, 해커가 그 사용자인 것처럼 시스템에 로그인하는 데 그대로 사용할 수 있습니다. 이게 큰 문제처럼 보이지 않을 수도 있습니다. 해커가 이미 시스템에 접근했다면, 왜 굳이 로그인이 필요할까요? 하지만 문제는 사람들이 여러 계정에 동일한 비밀번호를 자주 사용한다는 점입니다. 해커가 사용자 이름과 비밀번호를 알아내면, 그 정보를 다른 사이트에서도 사용할 수 있습니다. 그렇다면 이 문제를 어떻게 해결할 수 있을까요? 저장하기 전에 비밀번호를 암호화하세요. 이 과정을 흔히 “해싱(hashing)”이라고 하며, “솔팅(salting)”과 함께 적용할 수도 있습니다.

해싱은 입력한 비밀번호에 알고리즘을 적용하여 이를 암호화하는 과정입니다. 그런 다음 암호화된 결과를 데이터베이스에 저장할 수 있습니다. 이 비밀번호를 확인하려면, 시스템이 사용자가 입력한 값에 대해 동일한 해싱 과정을 수행하고, 그 출력 결과를 이전에 저장해 둔 해시 값(정답 비밀번호)과 비교할 수 있습니다. 대부분의 프로그래밍 언어에는 이를 대신 수행해 주는 내장 기능이 있습니다. 요약하자면, 데이터베이스에 평문 비밀번호를 저장하지 마세요.

중복 데이터

데이터베이스에 중복 데이터를 저장하는 것은 좋은 생각이 아닙니다. 중복 데이터는 데이터베이스의 더 많은 공간을 차지하는데, 데이터베이스가 크다면 그 양이 상당할 수 있습니다. 또한 여러 곳에서 데이터를 업데이트해야 하므로, 데이터를 업데이트할 때 문제가 발생할 수 있습니다. 유일한 예외는 데이터 웨어하우스를 생성하는 경우입니다. 이러한 유형의 데이터베이스는 업데이트보다 빠른 조회를 위해 최적화되어 있으며, 보통 중복 데이터를 포함합니다.

관계형 데이터베이스를 사용해 데이터를 저장할 때의 장점 중 하나는, 여러 테이블에 데이터를 저장하되 각 테이블이 하나의 엔터티를 나타내고, 그 엔터티들이 서로 연결된다는 점입니다. 이를 “정규화(normalization)”라고 합니다. 이렇게 하면 엔터티마다 하나의 테이블을 두고, ID 번호(또는 다른 키 값)를 사용해 테이블 간을 연결할 수 있습니다.

즉, 일부 값에 변경이 필요할 때 데이터를 업데이트하기가 더 쉽다는 뜻입니다. 또한 저장 공간을 절약할 수 있으며, 데이터를 변경할 때 성능을 향상시키는 경우가 많습니다.

이미지와 같은 파일

데이터베이스를 사용하면 이미지와 같은 파일을 데이터베이스의 테이블 안에 저장할 수 있습니다.

이제 Oracle의 BLOB 데이터 타입처럼 파일을 저장하기 위해 테이블과 컬럼을 만들 수는 있지만, 그렇다고 해서 그렇게 해야 한다는 뜻은 아닙니다. 데이터베이스 테이블에 파일을 저장한다는 것은 파일에 접근하기 위해 데이터베이스 로직(그리고 필요할 경우 애플리케이션 로직)을 사용해야 한다는 의미입니다. 이는 데이터베이스 크기를 늘리고 성능을 저하시킵니다. 또한 백업과 데이터 손상에 대응하기도 더 어렵게 만듭니다. 파일과 이미지를 저장하는 더 나은 방법은 파일 서버를 사용하는 것입니다. 파일 서버는 이를 위해 만들어졌습니다. 파일 서버를 사용하면 더 빠른 파일 접근, 더 쉬운 파일 메타데이터 접근, 그리고 더 쉬운 백업 및 복원 기능을 제공받을 수 있습니다.

신용카드 데이터

마지막으로, 꼭 필요하지 않다면 데이터베이스에 신용카드 정보를 저장해서는 안 됩니다.

여기에는 신용카드 소유자 이름, 카드 번호, CVV 번호, 유효 기간이 포함됩니다. 관련된 위험이 너무 큽니다. 해커가 여러분의 시스템에서 신용카드 데이터에 접근하게 되면, 회사와 고객 모두에게 큰 영향을 미칩니다. 또한 카드 번호를 저장한다면 엄격한 표준—즉 PCI DSS—을 준수하는지 확인하기 위해 외부 감사를 받아야 합니다. 이는 IT 부서에 더 많은 부담을 주며 추가 비용을 의미하기도 합니다. 더 나은 방법은 Authorize.net 또는 PayPal 같은 기존 솔루션을 사용하는 것입니다. 이러한 조직들은 이미 소프트웨어를 개발했고 규정 준수도 입증했으며, 많은 다른 회사들이 그들을 이용하고 신뢰하고 있습니다. 아예 신용카드 데이터를 저장하지 않는 것이 더 좋습니다. 그렇게 하는 것은 위험 대비 가치가 없으며, 다른 회사들이 더 잘하고 있습니다.

공유하기

더 알아보기

저자 소개

Asset Not Found

Ben Brumm

소프트웨어 개발자 & 비즈니스 분석가

Ben은 11년 이상의 경력을 가진 소프트웨어 개발자이자 비즈니스 분석가입니다. 호주 멜버른에 기반을 두고 있으며, 정규직으로 데이터베이스와 SQL을 다뤄왔을 뿐만 아니라 DatabaseStar.com 사이트의 창립자로서 오라클 데이터베이스 주제를 가르치고 있습니다. 소프트웨어와 데이터베이스에 대한 그의 열정은 1990년대 후반 고등학교 때 컴퓨터 수업을 시작하면서부터 시작되었고, 그 이후로 계속해서 더 커져 왔습니다.