2021.09.13

귀중한 정보 망친다··· 데이터베이스 보안 '지뢰' 12가지

Peter Wayner | CSO
오늘날 대부분의 기업 인프라에서 ‘데이터베이스’는 모든 비밀이 기다리는 곳이다. 부분적으로 이는 지극히 개인적이거나 굉장히 가치 있을 수 있는 정보의 은신처이자 대기실이며 활동 무대다. 모든 침입에 맞서 이러한 데이터베이스를 보호하는 일은 데이터베이스 관리자, 개발자, 데브옵스 팀에게 가장 중요한 일이다. 

안타깝게도, 그 일은 쉽지 않다. 제공 업체는 모든 도구를 제공하며, 적절한 보안 조치를 구축하고 문서화한다. 그런데도 (바보 같은 것이든 이해할 수 있는 것이든) 수십 가지의 잠재적인 오류와 실수가 존재하며, 이로 인해 데이터베이스 보호는 끝없는 과제가 된다. 

공격자가 악용하려고 하는 데이터베이스의 주요 취약점을 소개한다. 
 
ⓒGetty Images

1. 부적절한 액세스 관리
많은 데이터베이스가 자체 시스템에 상주하기 때문에 이 시스템은 가능한 한 잠겨 있어야 한다. 필수 사용자만 데이터베이스 관리자로 로그인할 수 있어야 하며, 로그인은 협소한 범위의 네트워크 및 기타 시스템으로 제한돼야 한다. 

방화벽은 IP주소를 차단할 수 있다. 동일한 규칙이 운영체제 계층에도 적용돼야 하며, 가상 머신에서 실행 중이라면 이는 하이퍼바이저 또는 클라우드 관리에도 적용돼야 한다. 이런 제한 조치는 소프트웨어 업데이트 및 문제 해결 작업을 지연시키지만 공격자가 갈 수 있는 경로를 제한하는 일은 그만한 가치를 지닌다. 

2. 손쉬운 물리적 접근
공격자가 서버실 안에서 무슨 짓을 할지 알 수 없다. 클라우드 회사와 코로케이션 시설은 접근이 제한되고 경비가 삼엄한 건물 내에 잠금 장치된 케이지를 제공한다. 데이터가 자체 데이터센터에 로컬로 보관돼 있다면 똑같은 규칙을 따라야 한다. 디스크 드라이브가 보관돼 있는 방에는 반드시 신뢰할 수 있는 소수만이 접근할 수 있도록 조치해야 한다.

3. 보호되지 않은 백업
데이터베이스 서버의 보안 작업은 훌륭하게 수행하면서도 백업 보안은 소홀히 하는 경우가 드물지 않다. 백업에도 동일한 정보가 들어 있기 때문에 똑같이 주의를 기울여야 한다. 정적 미디어(예: 테이프, 드라이브 등)는 금고에 보관하되, 가급적이면 원본과 다른 장소에 위치시켜 화재나 홍수로 원본이 손상되더라도 백업본은 피해를 보지 않게 해야 한다.

4. 암호화되지 않은 저장 데이터
데이터 스크램블링 알고리즘은 널리 테스트됐으며, 현재 표준에는 공개적으로 알려진 약점이 없기 때문에 신뢰할 수 있다. 이제 데이터베이스와 백업은 모든 저장 데이터를 쉽게 암호화할 수 있다. 

알고리즘과 구현이 안전하더라도 키는 주의 깊게 보호해야 한다. 클라우드 업체와 서버 개발 업체는 평균적인 워크로드와 별도로 신뢰할 수 있는 하드웨어를 만들어 키를 내부에 안전하게 보관하고 있다. 

시스템이 완벽하지 않다고 해도 없는 것보단 낫다. 데이터가 저장 상태에서 암호화된 상태로 일정 기간 유지될 예정이라면 키의 보관 장소는 다른 물리적 위치(가급적이면 오프라인)를 선호한다. 키를 출력한 문서를 금고에 넣는 경우도 있다. 

5. 프라이버시 보호 알고리즘 미사용
암호화는 키를 보호할 수만 있다면 데이터베이스의 물리적 복사본을 보호하는 데 좋은 도구다. 또 다양한 양질의 알고리즘은 데이터를 영구적으로 스크램블링한다. 모든 문제를 해결할 순 없지만 민감한 데이터를 모두 사용 가능한 상태로 유지할 필요가 없을 때는 매우 효과적일 수 있다. 

가장 간단한 방법은 이름을 임의의 가명으로 바꾸는 것일 수 있다. 수십 가지의 다른 접근법은 개인 데이터를 보호하기 위해 적정량의 연산을 사용하는 동시에 데이터베이스의 목표를 달성하기에 충분한 정보를 그대로 유지한다. 

6. 확산 통제의 부족
데이터가 사용될 때 이는 캐시와 실행 중인 서버에 복사된다. 데이터 스토리지 아키텍트의 목표는 복사본 수를 최소화하는 것과 데이터가 사용되지 않는 즉시 복사본이 파기되도록 하는 것이다. 많은 데이터베이스가 시스템 장애에 대비한 보호 기능으로 정기적인 미러링 또는 백업 옵션을 제공한다. 

이는 안정적인 서비스 제공에 필수적일 수 있지만 설계 단계에서 확산에 관해 주의 깊게 살펴보는 것이 필요하다. 때에 따라 서비스를 너무 많이 손상시키지 않으면서 무분별한 복사를 제한할 수 있다. 공격자가 침입할 수 있는 장소의 수를 제한하는 것이라면 비교적 느리고 중복이 적은 옵션을 선택하는 게 나을 수도 있다. 

7. 데이터베이스 통제 부족
최고의 데이터베이스는 수십 년에 걸친 끝없는 테스트와 보안 연구에 힘입어 발전한 결과물이다. 즉 좋은 데이터베이스를 선택하라는 의미다. 또 데이터베이스 제공업체들은 액세스 관리 및 제한에 사용하기 적절한 도구를 추가했다.

이를 사용해 적절한 앱만 적절한 테이블을 볼 수 있게 해야 한다. 모든 애플리케이션에 동일한 비밀번호를 재사용해서는 안 된다. 기본값을 사용하는 것도 당연히 안 된다. 가능하다면 로컬 네트워크나 로컬 프로세스로 접근을 제한해야 한다.

8. 취약한 보조 데이터베이스
많은 인프라에서 응답 속도를 높이기 위해 고속 인메모리 캐시(예: 레디스(Redis))를 사용한다. 이러한 보조 데이터베이스와 콘텐츠 전송 네트워크(CDN)는 데이터베이스에 동일한 정보의 복사본이 있는 경우가 많다. 기본 데이터베이스처럼 정확하게 구성해야 한다.

9. 데이터에 액세스할 수 있는 취약한 애플리케이션
신뢰할 수 있는 애플리케이션이 제대로 작동하지 않을 때, 특히 신뢰할 수 있는 애플리케이션이 모든 데이터에 액세스할 수 있다면 어떤 데이터베이스 보안도 쓸모가 없을 수 있다. 

한 가지 흔한 문제는 제대로 코딩되지 않은 앱을 속여 악성 SQL을 데이터베이스에 전달하도록 하는 SQL 인젝션 공격이다. 또 다른 문제는 애플리케이션 자체 보안이 취약한 경우다. 많은 아키텍처에서 애플리케이션은 모든 것을 본다. 애플리케이션이 사용자를 제대로 차단하지 못하면 이 모든 데이터가 밖으로 유출될 수 있다. 

10. 위험한 인터넷 노출
데이터베이스는 퍼블릭 액세스가 없는 네트워크에 상주하기 때문에 이상적인 후보다. 데이터베이스를 일반 인터넷에 개방하여 삶을 간단히 하고자 하는 개발자도 있지만 사소하지 않은 정보를 지키는 사람이라면 달리 생각해야 한다. 데이터베이스가 프론트엔드 서버와만 통신한다면 (데이터베이스는) 이러한 프론트엔드 서버만 도달할 수 있는 네트워크에 상주해도 무방하다. 

11. 무결성 관리 부족
최신 데이터베이스는 데이터세트에 오류와 불일치가 들어가지 않도록 하는 다양한 기능을 제공한다. 데이터에 스키마를 지정하면 개별 데이터 요소가 일정한 규칙을 준수하도록 할 수 있다. 트랜잭션 및 잠금을 사용하면 한 테이블이나 행이 업데이트되고, 다른 테이블이나 행은 업데이트되지 않을 때 오류가 발생하는 일을 방지할 수 있다. 

이러한 무결성 관리 옵션을 배포하면 연산 오버헤드가 추가되지만 최대한 많이 사용한다면 무작위적 실수의 영향을 줄이고, 사용자가 일관되지 않거나 잘못된 데이터를 삽입하는 일을 방지할 수 있다. 

12. 불필요한 데이터 보유
때때로 가장 안전한 해결책은 데이터베이스를 삭제하는 것이다. 오지 않을 수도 있는 미래를 위해 모든 정보를 저장하는 경우가 있다. 하지만 데이터 침해를 방지하려면 데이터를 삭제하는 게 가장 간단할 수 있다. 

향후 서비스 제공에 필요하지 않은 정보나 고객 측에서 보여 달라고 요청할 일이 없는 정보를 삭제하면 이를 보호해야 할 부담에서 해방될 수 있다. 만약 데이터가 다시 사용되지 않을 것이라고 확신할 수 없다면 액세스가 더욱더 제한된 딥 스토리지에 오프라인 백업본만 보관하고 온라인 복사본은 삭제하면 된다. ciokr@idg.co.kr

 



2021.09.13

귀중한 정보 망친다··· 데이터베이스 보안 '지뢰' 12가지

Peter Wayner | CSO
오늘날 대부분의 기업 인프라에서 ‘데이터베이스’는 모든 비밀이 기다리는 곳이다. 부분적으로 이는 지극히 개인적이거나 굉장히 가치 있을 수 있는 정보의 은신처이자 대기실이며 활동 무대다. 모든 침입에 맞서 이러한 데이터베이스를 보호하는 일은 데이터베이스 관리자, 개발자, 데브옵스 팀에게 가장 중요한 일이다. 

안타깝게도, 그 일은 쉽지 않다. 제공 업체는 모든 도구를 제공하며, 적절한 보안 조치를 구축하고 문서화한다. 그런데도 (바보 같은 것이든 이해할 수 있는 것이든) 수십 가지의 잠재적인 오류와 실수가 존재하며, 이로 인해 데이터베이스 보호는 끝없는 과제가 된다. 

공격자가 악용하려고 하는 데이터베이스의 주요 취약점을 소개한다. 
 
ⓒGetty Images

1. 부적절한 액세스 관리
많은 데이터베이스가 자체 시스템에 상주하기 때문에 이 시스템은 가능한 한 잠겨 있어야 한다. 필수 사용자만 데이터베이스 관리자로 로그인할 수 있어야 하며, 로그인은 협소한 범위의 네트워크 및 기타 시스템으로 제한돼야 한다. 

방화벽은 IP주소를 차단할 수 있다. 동일한 규칙이 운영체제 계층에도 적용돼야 하며, 가상 머신에서 실행 중이라면 이는 하이퍼바이저 또는 클라우드 관리에도 적용돼야 한다. 이런 제한 조치는 소프트웨어 업데이트 및 문제 해결 작업을 지연시키지만 공격자가 갈 수 있는 경로를 제한하는 일은 그만한 가치를 지닌다. 

2. 손쉬운 물리적 접근
공격자가 서버실 안에서 무슨 짓을 할지 알 수 없다. 클라우드 회사와 코로케이션 시설은 접근이 제한되고 경비가 삼엄한 건물 내에 잠금 장치된 케이지를 제공한다. 데이터가 자체 데이터센터에 로컬로 보관돼 있다면 똑같은 규칙을 따라야 한다. 디스크 드라이브가 보관돼 있는 방에는 반드시 신뢰할 수 있는 소수만이 접근할 수 있도록 조치해야 한다.

3. 보호되지 않은 백업
데이터베이스 서버의 보안 작업은 훌륭하게 수행하면서도 백업 보안은 소홀히 하는 경우가 드물지 않다. 백업에도 동일한 정보가 들어 있기 때문에 똑같이 주의를 기울여야 한다. 정적 미디어(예: 테이프, 드라이브 등)는 금고에 보관하되, 가급적이면 원본과 다른 장소에 위치시켜 화재나 홍수로 원본이 손상되더라도 백업본은 피해를 보지 않게 해야 한다.

4. 암호화되지 않은 저장 데이터
데이터 스크램블링 알고리즘은 널리 테스트됐으며, 현재 표준에는 공개적으로 알려진 약점이 없기 때문에 신뢰할 수 있다. 이제 데이터베이스와 백업은 모든 저장 데이터를 쉽게 암호화할 수 있다. 

알고리즘과 구현이 안전하더라도 키는 주의 깊게 보호해야 한다. 클라우드 업체와 서버 개발 업체는 평균적인 워크로드와 별도로 신뢰할 수 있는 하드웨어를 만들어 키를 내부에 안전하게 보관하고 있다. 

시스템이 완벽하지 않다고 해도 없는 것보단 낫다. 데이터가 저장 상태에서 암호화된 상태로 일정 기간 유지될 예정이라면 키의 보관 장소는 다른 물리적 위치(가급적이면 오프라인)를 선호한다. 키를 출력한 문서를 금고에 넣는 경우도 있다. 

5. 프라이버시 보호 알고리즘 미사용
암호화는 키를 보호할 수만 있다면 데이터베이스의 물리적 복사본을 보호하는 데 좋은 도구다. 또 다양한 양질의 알고리즘은 데이터를 영구적으로 스크램블링한다. 모든 문제를 해결할 순 없지만 민감한 데이터를 모두 사용 가능한 상태로 유지할 필요가 없을 때는 매우 효과적일 수 있다. 

가장 간단한 방법은 이름을 임의의 가명으로 바꾸는 것일 수 있다. 수십 가지의 다른 접근법은 개인 데이터를 보호하기 위해 적정량의 연산을 사용하는 동시에 데이터베이스의 목표를 달성하기에 충분한 정보를 그대로 유지한다. 

6. 확산 통제의 부족
데이터가 사용될 때 이는 캐시와 실행 중인 서버에 복사된다. 데이터 스토리지 아키텍트의 목표는 복사본 수를 최소화하는 것과 데이터가 사용되지 않는 즉시 복사본이 파기되도록 하는 것이다. 많은 데이터베이스가 시스템 장애에 대비한 보호 기능으로 정기적인 미러링 또는 백업 옵션을 제공한다. 

이는 안정적인 서비스 제공에 필수적일 수 있지만 설계 단계에서 확산에 관해 주의 깊게 살펴보는 것이 필요하다. 때에 따라 서비스를 너무 많이 손상시키지 않으면서 무분별한 복사를 제한할 수 있다. 공격자가 침입할 수 있는 장소의 수를 제한하는 것이라면 비교적 느리고 중복이 적은 옵션을 선택하는 게 나을 수도 있다. 

7. 데이터베이스 통제 부족
최고의 데이터베이스는 수십 년에 걸친 끝없는 테스트와 보안 연구에 힘입어 발전한 결과물이다. 즉 좋은 데이터베이스를 선택하라는 의미다. 또 데이터베이스 제공업체들은 액세스 관리 및 제한에 사용하기 적절한 도구를 추가했다.

이를 사용해 적절한 앱만 적절한 테이블을 볼 수 있게 해야 한다. 모든 애플리케이션에 동일한 비밀번호를 재사용해서는 안 된다. 기본값을 사용하는 것도 당연히 안 된다. 가능하다면 로컬 네트워크나 로컬 프로세스로 접근을 제한해야 한다.

8. 취약한 보조 데이터베이스
많은 인프라에서 응답 속도를 높이기 위해 고속 인메모리 캐시(예: 레디스(Redis))를 사용한다. 이러한 보조 데이터베이스와 콘텐츠 전송 네트워크(CDN)는 데이터베이스에 동일한 정보의 복사본이 있는 경우가 많다. 기본 데이터베이스처럼 정확하게 구성해야 한다.

9. 데이터에 액세스할 수 있는 취약한 애플리케이션
신뢰할 수 있는 애플리케이션이 제대로 작동하지 않을 때, 특히 신뢰할 수 있는 애플리케이션이 모든 데이터에 액세스할 수 있다면 어떤 데이터베이스 보안도 쓸모가 없을 수 있다. 

한 가지 흔한 문제는 제대로 코딩되지 않은 앱을 속여 악성 SQL을 데이터베이스에 전달하도록 하는 SQL 인젝션 공격이다. 또 다른 문제는 애플리케이션 자체 보안이 취약한 경우다. 많은 아키텍처에서 애플리케이션은 모든 것을 본다. 애플리케이션이 사용자를 제대로 차단하지 못하면 이 모든 데이터가 밖으로 유출될 수 있다. 

10. 위험한 인터넷 노출
데이터베이스는 퍼블릭 액세스가 없는 네트워크에 상주하기 때문에 이상적인 후보다. 데이터베이스를 일반 인터넷에 개방하여 삶을 간단히 하고자 하는 개발자도 있지만 사소하지 않은 정보를 지키는 사람이라면 달리 생각해야 한다. 데이터베이스가 프론트엔드 서버와만 통신한다면 (데이터베이스는) 이러한 프론트엔드 서버만 도달할 수 있는 네트워크에 상주해도 무방하다. 

11. 무결성 관리 부족
최신 데이터베이스는 데이터세트에 오류와 불일치가 들어가지 않도록 하는 다양한 기능을 제공한다. 데이터에 스키마를 지정하면 개별 데이터 요소가 일정한 규칙을 준수하도록 할 수 있다. 트랜잭션 및 잠금을 사용하면 한 테이블이나 행이 업데이트되고, 다른 테이블이나 행은 업데이트되지 않을 때 오류가 발생하는 일을 방지할 수 있다. 

이러한 무결성 관리 옵션을 배포하면 연산 오버헤드가 추가되지만 최대한 많이 사용한다면 무작위적 실수의 영향을 줄이고, 사용자가 일관되지 않거나 잘못된 데이터를 삽입하는 일을 방지할 수 있다. 

12. 불필요한 데이터 보유
때때로 가장 안전한 해결책은 데이터베이스를 삭제하는 것이다. 오지 않을 수도 있는 미래를 위해 모든 정보를 저장하는 경우가 있다. 하지만 데이터 침해를 방지하려면 데이터를 삭제하는 게 가장 간단할 수 있다. 

향후 서비스 제공에 필요하지 않은 정보나 고객 측에서 보여 달라고 요청할 일이 없는 정보를 삭제하면 이를 보호해야 할 부담에서 해방될 수 있다. 만약 데이터가 다시 사용되지 않을 것이라고 확신할 수 없다면 액세스가 더욱더 제한된 딥 스토리지에 오프라인 백업본만 보관하고 온라인 복사본은 삭제하면 된다. ciokr@idg.co.kr

 

X