데이터베이스 암호화

Database encryption

데이터베이스 암호화는 일반적으로 알고리즘을 사용하여 데이터베이스에 저장된 데이터를 먼저 해독하지 않고 이해할 수 없는 "주변 텍스트"로 변환하는 프로세스로 정의할 수 있다.[1]따라서 데이터베이스 암호화의 목적은 데이터베이스에 저장된 데이터가 잠재적으로 "악의적인" 의도를 가진 개인이 접근하지 못하도록 보호하는 것이라고 말할 수 있다.[2]또한 데이터베이스를 암호화하는 행위는 "의미 없는" 암호화된 데이터가 해커에게 거의 또는 전혀 쓸모가 없기 때문에 앞에서 언급한 데이터베이스를 해킹하는 개인에 대한 동기를 감소시킨다.[3]데이터베이스 암호화에 사용할 수 있는 여러 기술과 기술이 있으며, 그 중 가장 중요한 것은 이 기사에 자세히 설명될 것이다.

투명/외부 데이터베이스 암호화

투명 데이터 암호화(흔히 TDE로 약칭)는 전체 데이터베이스를 암호화하는 데 사용되며, [2]따라서 "정지 상태의 데이터"[4]를 암호화하는 것이 포함된다.유휴 데이터는 일반적으로 네트워크를 통해 현재 편집되거나 푸시되지 않는 "비활성" 데이터로 정의할 수 있다.[5]예를 들어 컴퓨터에 저장된 텍스트 파일은 열어서 편집할 때까지 "정지 상태"가 된다.저장된 데이터는 테이프나 하드 디스크 드라이브와 같은 물리적 스토리지 미디어 솔루션에 저장된다.[6]물리적 저장 매체에 민감한 데이터를 대량으로 저장하는 행위는 당연히 보안과 도난의 우려를 불러일으킨다.TDE는 물리적 저장 매체의 데이터를 훔칠 의도가 있는 악의적인 개인이 읽을 수 없도록 한다.[7]읽을 수 없는 데이터는 가치가 없으므로 도난에 대한 동기를 감소시킨다.아마도 TDE에 기인하는 가장 중요한 강점은 TDE의 투명성일 것이다.TDE가 모든 데이터를 암호화하는 것을 감안하면, TDE가 올바르게 실행되기 위해서는 응용 프로그램을 변경할 필요가 없다고 말할 수 있다.[8]TDE는 데이터베이스 백업뿐만 아니라 데이터베이스 전체를 암호화한다는 점에 유의해야 한다.TDE의 투명한 요소는 TDE가 "페이지 수준"에서 암호화하는 사실과 관련이 있는데, 이는 기본적으로 데이터가 시스템의 메모리에 호출될 때 데이터가 저장되고 해독될 때 암호화된다는 것을 의미한다.[9]데이터베이스 내용은 흔히 "데이터베이스 암호화 키"[2]라고 부르는 대칭 키를 사용하여 암호화된다.

컬럼 레벨 암호화

칼럼 수준의 암호화를 설명하기 위해서는 기본적인 데이터베이스 구조를 개략적으로 설명하는 것이 중요하다.일반적인 관계형 데이터베이스는 각각 데이터 행이 있는 열로 구분되는 테이블로 나뉜다.[10]TDE는 일반적으로 전체 데이터베이스를 암호화하는 반면, 열 수준 암호화는 데이터베이스 내의 개별 열을 암호화할 수 있도록 허용한다.[11]컬럼 레벨 암호화의 세분화가 전체 데이터베이스를 암호화하는 것과 비교할 때 특정 장단점이 발생하도록 하는 것이 중요하다.첫째, 개별 열 암호화 기능을 통해 TDE 등 전체 데이터베이스를 암호화하는 암호화 시스템에 비해 컬럼 레벨 암호화가 상당히 유연할 수 있으며, 둘째, 데이터베이스 내 각 열에 대해 완전히 고유하고 별도의 암호화 키를 사용할 수 있다.이것은 효과적으로 무지개표 생성의 어려움을 증가시키므로 각 열에 저장된 데이터가 손실되거나 유출될 가능성이 적다는 것을 의미한다.열 수준 데이터베이스 암호화와 관련된 주요 단점은 속도 또는 속도 손실이다.동일한 데이터베이스에서 서로 다른 고유 키로 별도의 열을 암호화하면 데이터베이스 성능이 저하될 수 있으며, 데이터베이스 내용을 색인화하거나 검색할 수 있는 속도도 감소할 수 있다.[12]

필드 레벨 암호화

암호화된 필드에 대해 암호 해독할 필요 없이 데이터베이스 연산(검색 또는 산술 연산 등)을 제공하는 실험 작업이 이루어지고 있다.[13]강력한 암호화는 무작위화되어야 한다 - 매번 다른 결과가 생성되어야 한다.이것은 확률론적 암호화라고 알려져 있다.필드 레벨 암호화는 무작위 암호화보다 약하지만 데이터 암호 해독 없이 평등을 테스트할 수 있다.[14]

파일 시스템 수준 암호화

주요 기사: 파일 시스템 수준 암호화

EFS(파일 시스템 암호화)

주요 기사:파일 시스템 암호화

기존의 데이터베이스 암호화 기법은 일반적으로 데이터베이스의 내용을 암호화하고 해독한다는 점에 유의해야 한다.데이터베이스는 기존 운영 체제(OS) 위에서 실행되는 "데이터베이스 관리 시스템"(DBMS)에 의해 관리된다.[15]이는 암호화된 데이터베이스가 접근 가능하고 잠재적으로 취약한 운영 체제에서 실행될 수 있기 때문에 잠재적인 보안 문제를 야기한다.EFS는 데이터베이스 시스템의 일부가 아닌 데이터를 암호화할 수 있으며, 이는 데이터베이스 파일만 암호화할 수 있는 TDE와 같은 시스템과 비교할 때 EFS의 암호화 범위가 훨씬 넓다는 것을 의미한다.[citation needed]EFS는 암호화 범위를 넓히지만 데이터베이스 성능도 저하되고 시스템 관리자가 EFS를 사용하기 위해 운영 체제 액세스를 요구함에 따라 관리 문제를 야기할 수 있다.성능 관련 문제로 인해 EFS는 일반적으로 빈번한 데이터베이스 입력과 출력이 필요한 데이터 저장 애플리케이션에는 사용되지 않는다.성능 문제를 상쇄하기 위해 EFS 시스템을 사용자가 거의 없는 환경에서 사용하는 것이 권장되는 경우가 많다.[16]

전체 디스크 암호화

기본 문서: 전체 디스크 암호화

BitLocker는 EFS와 관련된 동일한 성능 문제를 가지고 있지 않다.[16]

대칭 및 비대칭 데이터베이스 암호화

대칭 암호화의 시각적 시연

대칭 데이터베이스 암호화

데이터베이스 암호화의 맥락에서 대칭 암호화는 저장되고 데이터베이스에서 호출되는 데이터에 개인 키를 적용하는 것을 포함한다.이 개인 키는 먼저 해독되지 않고 읽을 수 없게 만드는 방식으로 데이터를 변경한다.[17]데이터는 저장 시 암호화되며, 사용자가 개인 키를 알고 있다는 점을 감안하여 열면 암호 해독된다.따라서 데이터를 데이터베이스를 통해 공유하려면 수신 개인이 데이터를 해독하고 보기 위해 송신자가 사용하는 비밀키의 사본을 가지고 있어야 한다.[18]대칭 암호화와 관련된 분명한 단점은 개인 키가 데이터에 접근해서는 안 되는 개인에게 확산될 경우 민감한 데이터가 유출될 수 있다는 것이다.[17]그러나 암호화 프로세스에는 하나의 키만 관여하고 있다는 점을 감안할 때 일반적으로 속도는 대칭 암호화의 장점이라고 할 수 있다.[19]

비대칭 데이터베이스 암호화

비대칭 암호화는 개인 키와 공용 키라는 두 가지 유형의 키를 암호화 방법에 통합함으로써 대칭 암호화를 확대한다.[20]공개 키는 누구나 접근할 수 있고 한 명의 사용자만이 사용할 수 있는 비밀키인 반면 개인키는 한 명의 사용자만이 사용할 수 있는 비밀키다.[21]대부분의 시나리오에서 공용 키는 암호화 키인 반면 개인 키는 암호 해독 키인 것이다.예를 들어, 만약 개인 A가 비대칭 암호화를 이용하여 개인 B에게 메시지를 보내고자 한다면, 개인 B의 공개키를 이용하여 메시지를 암호화한 후 암호화된 버전을 송신할 것이다.그러면 개인 B는 개인 키를 사용하여 메시지를 해독할 수 있을 것이다.개인 C의 개인 키가 개인 B의 개인 키와 같지 않기 때문에 개인 C는 개인 A의 메시지를 해독할 수 없을 것이다.[22]비대칭 암호화는 두 개의 별도 키가 암호화 및 암호 해독 프로세스를 처리하기 때문에 개인 키를 공유할 필요가 없다는 점에서 대칭 데이터베이스 암호화에 비해 더 안전하다고 설명되는 경우가 많다.[23]성능상의 이유로, 비대칭 암호화는 대칭 암호화로 행해지는 데이터를 암호화하는 것이 아니라 키 관리에 사용된다.

키 관리

'대칭 & 비대칭 데이터베이스 암호화' 섹션에서는 사용자가 키를 교환하는 기본적인 예를 들어 공용 키와 개인 키의 개념을 소개했다.키를 교환하는 행위는 많은 다른 개인들이 서로 의사소통할 필요가 있을 때 물류상의 관점에서 비실용적이 된다.데이터베이스 암호화에서 시스템은 키의 저장과 교환을 처리한다.이 과정을 키 매니지먼트라고 한다.암호화 키를 제대로 관리·저장하지 않으면 매우 민감한 데이터가 유출될 수 있다.또한, 키 관리 시스템이 키를 삭제하거나 분실할 경우, 해당 키를 통해 암호화된 정보도 본질적으로 "잃어버린" 정보로 렌더링된다.핵심 경영 물류에 대한 복잡성도 고려해야 할 주제다.기업이 사용하는 어플리케이션의 수가 증가함에 따라 저장 및 관리해야 하는 키의 수도 증가한다.따라서 모든 애플리케이션의 키를 하나의 채널을 통해 관리할 수 있는 방법을 확립할 필요가 있는데, 이를 엔터프라이즈 키 관리라고도 한다.[24]엔터프라이즈 키 관리 솔루션은 기술 산업의 수많은 공급업체에 의해 판매된다.이러한 시스템은 기본적으로 중앙 집중화된 키 관리 솔루션을 제공하여 관리자가 하나의 허브를 통해 시스템의 모든 키를 관리할 수 있도록 한다.[25]따라서 엔터프라이즈 키 관리 솔루션의 도입은 데이터베이스 암호화라는 맥락에서 키 관리와 관련된 리스크를 줄일 수 있을 뿐만 아니라, 많은 개인이 수동으로 키를 공유하려고 할 때 발생하는 물류상의 문제를 줄일 수 있는 잠재력을 가지고 있다고 할 수 있다.[24]

해싱

해싱은 암호와 같은 민감한 데이터를 보호하기 위한 방법으로 데이터베이스 시스템에서 사용되지만, 데이터베이스 참조의 효율성을 높이는 데도 사용된다.[26]입력된 데이터는 해싱 알고리즘에 의해 조작된다.해싱 알고리즘은 입력된 데이터를 고정된 길이의 문자열로 변환하여 데이터베이스에 저장할 수 있다.해싱 시스템은 이제 윤곽이 드러날 두 가지 결정적으로 중요한 특성을 가지고 있다.첫째, 해시는 "독특하고 반복 가능한" 것이다.예를 들어, 같은 해싱 알고리즘을 통해 "cat"이라는 단어를 여러 번 실행하면 항상 같은 해시를 산출하게 되지만, "cat"이 하는 것과 같은 해시를 반환할 단어를 찾기는 극히 어렵다.[27]둘째, 해싱 알고리즘은 되돌릴 수 없다.이것을 위에 제공된 예와 다시 연관시키기 위해서는 해싱 알고리즘의 출력을 원래 입력인 "cat"[28]으로 되돌리는 것이 거의 불가능할 것이다.데이터베이스 암호화의 맥락에서 해싱은 암호 시스템에서 자주 사용된다.사용자가 처음 암호를 만들 때 해싱 알고리즘을 통해 실행되며 해시로 저장된다.사용자가 다시 웹 사이트에 로그인하면 입력한 암호가 해싱 알고리즘을 통해 실행된 다음 저장된 해시와 비교된다.[29]해시가 고유하다는 점을 감안하면 해시 두 개가 일치하면 사용자가 정확한 암호를 입력했다고 한다.대표적인 해시함수의 예로는 SHA(Secure Hash Algorithm) 256이 있다.[30]

솔팅

데이터베이스 암호화의 맥락에서 암호 관리를 위해 해싱을 사용할 때 발생하는 한 가지 문제는 악성 사용자가 시스템이 사용하는 특정 해싱 알고리즘에 대해 잠재적으로 해시 테이블 무지개 테이블을[31] 사용할 수 있다는 사실이다.이것은 효과적으로 개인이 해시의 암호를 해독할 수 있게 하고, 따라서 저장된 암호에 대한 액세스를 가질 수 있게 할 것이다.[32]이 문제에 대한 해결책은 해시를 '소금'하는 것이다.솔팅은 데이터베이스의 암호 이상의 암호화를 수행하는 과정이다.해시될 줄에 더 많은 정보가 추가될수록 무지개 테이블을 결합하는 것은 더 어려워진다.예를 들어, 시스템은 사용자의 전자 메일과 암호를 단일 해시로 결합할 수 있다.해시의 복잡성이 이처럼 증가한다는 것은 무지개 테이블이 생성될 가능성이 훨씬 더 낮다는 것을 의미한다.이것은 자연스럽게 민감한 데이터 손실의 위협이 솔트 해시를 통해 최소화된다는 것을 의미한다.[33]

후추

어떤 시스템은 해싱 시스템에 소금 외에 "피퍼"를 통합한다.후추 체계는 논란의 여지가 있지만, 여전히 후추 체계의 용도를 설명할 필요가 있다.[31]후추는 소금에 절인 해시 암호에 첨가된 값이다.[34]이 후추는 종종 하나의 웹사이트나 서비스에 고유하며, 일반적으로 데이터베이스에 저장된 모든 암호에 동일한 후추가 추가된다는 점에 유의해야 한다.[35]이론적으로, 패스워드 해싱 시스템에 고추를 포함시키는 것은 시스템 차원의 특수성을 감안할 때 무지개 (입력 : 해시) 테이블의 위험을 줄일 수 있는 잠재력을 가지고 있지만, 후추 구현의 현실적 이익은 크게 논란이 되고 있다.[34]

응용 프로그램 수준 암호화

응용 프로그램 수준 암호화에서는 암호화할 데이터를 생성하거나 수정하는 데 사용한 응용 프로그램에 의해 데이터 암호화 프로세스가 완료된다.기본적으로 이것은 데이터가 데이터베이스에 기록되기 전에 암호화된다는 것을 의미한다.암호화에 대한 이 독특한 접근방식은 응용 프로그램이 자신의 사용자에 대해 알고 있는 정보(예: 자격이나 역할)에 근거하여 암호화 프로세스를 각 사용자에 맞게 조정할 수 있도록 한다.[35]

유진 필얀케비치에 따르면 "애플리케이션 레벨 암호화는 경계선이 없고 노출이 많은 클라우드 시스템으로 대체적으로 이동하면서 보안 요건이 강화된 시스템에 좋은 관행이 되고 있다"고 한다.[36]

애플리케이션 레벨 암호화의 이점

애플리케이션 레벨 암호화의 가장 중요한 장점 중 하나는 애플리케이션 레벨 암호화가 기업이 사용하는 암호화 프로세스를 단순화할 수 있는 잠재력을 가지고 있다는 점이다.애플리케이션이 데이터베이스에서 쓰기/수정하는 데이터를 암호화하는 경우, 보조 암호화 도구를 시스템에 통합할 필요가 없을 것이다.두 번째 주요 장점은 절도의 중요한 주제와 관련이 있다.데이터가 서버에 기록되기 전에 암호화된다는 점을 감안할 때, 해커는 중요한 데이터를 해독하기 위해 데이터베이스의 내용을 암호화하고 해독하는 데 사용되었던 애플리케이션뿐만 아니라 데이터베이스 컨텐츠에 대한 접근성도 가질 필요가 있을 것이다.[37]

애플리케이션 수준 암호화의 단점

애플리케이션 수준 암호화의 첫 번째 중요한 단점은 기업이 사용하는 애플리케이션을 수정하여 데이터 자체를 암호화할 필요가 있다는 것이다.이것은 상당한 시간과 다른 자원을 소비할 수 있는 잠재력을 가지고 있다.기회비용의 성격을 고려할 때, 기업들은 애플리케이션 수준 암호화가 투자 가치가 있다고 생각하지 않을 수 있다.또한 애플리케이션 수준 암호화는 데이터베이스 성능에 제한적인 영향을 미칠 수 있다.데이터베이스의 모든 데이터가 다수의 다른 응용프로그램에 의해 암호화되면, 데이터베이스에서 데이터를 색인하거나 검색하는 것은 불가능해진다.이것을 기초적인 사례의 형태로 현실에 근거를 둔다면: 30개 국어로 쓰여진 책의 경우 하나의 언어로 용어집을 구성하는 것은 불가능할 것이다.마지막으로, 데이터를 암호화하고 데이터베이스에 쓰기 위한 권한과 접근 권한을 여러 개의 서로 다른 애플리케이션이 필요로 하기 때문에 키 관리의 복잡성이 증가한다.[37]

데이터베이스 암호화 위험

데이터베이스 암호화에 대해 논의할 때 프로세스에 관련된 위험에 대해 반드시 알아야 한다.첫 번째 리스크 세트는 키 관리와 관련이 있다.개인 키가 "격리된 시스템"에서 관리되지 않는 경우, 악의적인 의도를 가진 시스템 관리자는 접근 가능한 키를 사용하여 중요한 데이터를 해독할 수 있는 능력을 가질 수 있다.키의 기본 원리는 또한 잠재적으로 파괴적인 위험을 초래한다: 키가 없어지면 암호화된 데이터도 없어진다. 키 없는 암호 해독은 거의 불가능하다.[38]

참조

  1. ^ "What is Database Encryption and Decryption? - Definition from Techopedia". Techopedia.com. Retrieved November 4, 2015.
  2. ^ a b c "Transparent Data Encryption with Azure SQL Database". msdn.microsoft.com. Retrieved November 4, 2015.
  3. ^ "SQL SERVER - Introduction to SQL Server Encryption and Symmetric Key Encryption Tutorial with Script". Journey to SQL Authority with Pinal Dave. April 28, 2009. Retrieved October 25, 2015.
  4. ^ "Transparent Data Encryption (TDE)". msdn.microsoft.com. Retrieved October 25, 2015.
  5. ^ "What is data at rest? - Definition from WhatIs.com". SearchStorage. Retrieved October 25, 2015.
  6. ^ "Encryption techniques and products for hardware-based data storage security". ComputerWeekly. Retrieved October 31, 2015.
  7. ^ "Storage Encryption Solutions". www.thales-esecurity.com. Retrieved October 25, 2015.
  8. ^ "Transparent Data Encryption (TDE) in SQL Server — DatabaseJournal.com". www.databasejournal.com. Retrieved November 2, 2015.
  9. ^ "Using Transparent Data Encryption". sqlmag.com. Archived from the original on October 14, 2017. Retrieved November 2, 2015.
  10. ^ "A Tutorial on Database Concepts, SQL using MySQL". www.atlasindia.com. Retrieved November 4, 2015.
  11. ^ "SQL Server Encryption Options". sqlmag.com. Archived from the original on October 27, 2017. Retrieved November 2, 2015.
  12. ^ "Differences Between Whole Database and Column Encryption". www.netlib.com. Retrieved November 2, 2015.
  13. ^ "Optimized and Controlled Provisioning of Encrypted Outsourced Data" (PDF). www.fkerschbaum.org.
  14. ^ Suciu, Dan (2012). "Technical Perspective: SQL on an Encrypted Database". Communications of the ACM. doi:10.1145/2330667.2330690. S2CID 33705485.
  15. ^ Spooner, David L.; Gudes, E. (May 1, 1984). "A Unifying Approach to the Design of a Secure Database Operating System". IEEE Transactions on Software Engineering. SE-10 (3): 310–319. doi:10.1109/TSE.1984.5010240. ISSN 0098-5589. S2CID 15407701.
  16. ^ a b "Database Encryption in SQL Server 2008 Enterprise Edition". technet.microsoft.com. Retrieved November 3, 2015.
  17. ^ a b "Description of Symmetric and Asymmetric Encryption". support.microsoft.com. Retrieved October 25, 2015.
  18. ^ "How Encryption Works". HowStuffWorks. April 6, 2001. Retrieved October 25, 2015.
  19. ^ "Asymmetric vs. Symmetric – Hacking with PHP - Practical PHP". www.hackingwithphp.com. Retrieved November 3, 2015.
  20. ^ "How Encryption Works". HowStuffWorks. April 6, 2001. Retrieved November 1, 2015.
  21. ^ Young, Dr. Bill. "Foundations of Computer Security Lecture 44: Symmetric vs. Asymmetric Encryption" (PDF). University of Texas at Austin. Archived from the original (PDF) on March 5, 2016. Retrieved November 1, 2015.
  22. ^ "What is asymmetric cryptography and how do I use it?". Two Factor Authenticity. Retrieved November 1, 2015.
  23. ^ "Advantages and Disadvantages of Asymmetric and Symmetric Cryptosystems" (PDF). University of Babylon. Retrieved November 3, 2015.
  24. ^ a b "Encryption key management is vital to securing enterprise data storage". ComputerWeekly. Retrieved November 2, 2015.
  25. ^ "What is Enterprise Key Management?". web.townsendsecurity.com. Retrieved November 2, 2015.
  26. ^ "What is hashing? - Definition from WhatIs.com". SearchSQLServer. Retrieved November 1, 2015.
  27. ^ "How data encryption software creates one way hash files using the sha1 hashing algorithm". www.metamorphosite.com. Retrieved November 1, 2015.
  28. ^ "Understanding Encryption – Symmetric, Asymmetric, & Hashing". Atomic Spin. November 20, 2014. Retrieved November 1, 2015.
  29. ^ "PHP: Password Hashing - Manual". php.net. Retrieved November 1, 2015.
  30. ^ "JavaScript Implementation of SHA-256 Cryptographic Hash Algorithm Movable Type Scripts". www.movable-type.co.uk. Retrieved November 3, 2015.
  31. ^ a b "Salt and pepper - How to encrypt database passwords". blog.kablamo.org. Retrieved November 1, 2015.
  32. ^ "PHP: Password Hashing - Manual". php.net. Retrieved November 1, 2015.
  33. ^ "Why You Should Always Salt Your Hashes - Web Development in Brighton - Added Bytes". Added Bytes. Retrieved November 1, 2015.
  34. ^ a b "ircmaxell's blog: Properly Salting Passwords, The Case Against Pepper". blog.ircmaxell.com. Retrieved November 2, 2015.
  35. ^ a b "Application Encryption from Thales e-Security". www.thales-esecurity.com. Retrieved October 25, 2015.
  36. ^ Pilyankevich, Eugene (December 18, 2020). "Application Level Encryption for Software Architects". InfoQ.{{cite web}}: CS1 maint : url-status (링크)
  37. ^ a b Baccam, Tanya (April 2010). "Transparent Data Encryption: New Technologies and Best Practices for Database Encryption". Sans.org. SANS Institute. Retrieved October 25, 2015.
  38. ^ "Database Encryption: Challenges, Risks, and Solutions". www.thales-esecurity.com. Retrieved October 25, 2015.