알 수없는 소스에서 백업을 복원 할 때의 보안 영향

시나리오 : 데이터베이스 백업을받은 후 이미 다른 데이터베이스를 호스팅하고있는 서버로 데이터베이스를 복원하라는 지시를 받았지만 백업에 포함 된 내용이나 소스의 신뢰 여부에 대한 유용한 정보는 제공되지 않습니다.

질문 1 : 악의적 일 수있는 백업 복원의 잠재적 영향은 무엇입니까?

질문 2 : 잠재적으로 악의적 인 백업을 복원하는 것으로부터 서버 / 다른 데이터베이스의 데이터를 보호하기 위해 무엇을 할 수 있습니까? RESTORE VERIFYONLY좋은 첫 걸음 인 것 같습니다. 궁극적 인 대답은 아마도 '외부 세계에 액세스 할 수없는 샌드 박스 VM에 데이터베이스를 복원하는 것'이지만 옵션이 테이블 밖이라고 가정 해 봅시다. 이 상황에서 다른 무엇을해야합니까?

데이터베이스에는 "sa"로그인의 비밀번호를 변경하거나 모든 데이터베이스를 삭제하는 절차 인 악성 코드가 포함될 수 있습니다. 그러나 내가 문제를 일으킨다는 것을 알 수있는 유일한 방법은 개인이 데이터베이스를 복원 한 다음 해당 데이터베이스 내에서 코드를 수동으로 실행하는 것입니다. 자동화 된 방식으로 실행되지 않습니다.

SQL Server가 서버로 복원 할 때 데이터베이스 내에서 약간의 코드를 자동으로 실행하도록 데이터베이스 내에 적용 할 수있는 설정은 없습니다. 만일 그렇다면 Microsoft는 제품에 대한 Common Criteria 인증을 잃을 것으로 예상합니다. 그것은 DBMS에서 나에게 허용 한 큰 버그입니다.

할 수있는 몇 가지 예방 단계가 있습니다.

1. 한 명의 sysadmin 만 복원 된 데이터베이스에 액세스 할 수 있는지 확인하십시오.
2. 복원이 완료된 후 DB를 단일 사용자 모드로 설정하십시오.
3. 이 데이터베이스 내의 모든 저장 프로 시저 및 함수와 트리거 내부의 코드를 확인하십시오.
4. 무결성 문제가 없는지 확인하려면 dbcc checkdb를 수행하십시오.
5. 데이터베이스에 액세스 한 적이있는 사용자를 확인하고 모두 제거하십시오.
6. 사용자가 확인한 특정 개체로 제한되는 액세스 허용을 시작하십시오.

Shawn이 말했듯이 vbalid로 보이는 일부 저장 프로 시저에 다른 악성 코드의 실행 파일이 없으면 코드가 자체적으로 실행되지 않습니다. 다중 사용자 모드로 전환하기 전에 각각의 코드를 확인해야하는 이유입니다.

여기에 도달하고 있지만 적어도 하나의 위험한 시나리오를 생각할 수 있습니다. filetable 이있는 데이터베이스를 복원하면 해당 파일이 기본적으로 네트워크에 있습니다 (특히 SQL Server에 있음). 바이러스를 복원 할 수 있습니다.

물론 그 자체로는 아무것도하지 않습니다. 바이러스가 갑자기 지각 적이지는 않지만 사용자가 파일에 액세스하려고하면 감염 될 수 있습니다. (이봐 요. 제가 연락하고 있다고 했어요.) 외부 해커가 멀웨어를 문에 넣고 싶어하는 시나리오를 계획 중입니다. 그런 다음 회계 담당자에게 "이 파일은 다음과 같습니다. \ sqlserver \ filetableshare \" myvirus.exe "-검색 시점에 방화벽을 통과했으며 이제 내부 바이러스 백신 및 맬웨어 방지 도구를 사용합니다.

VERIFYONLY REVERYYONLY는 좋은 첫 번째 단계 인 것 같습니다. 궁극적 인 대답은 아마도 '외부 세계에 대한 액세스 권한이없는 샌드 박스 VM에 데이터베이스를 복원하는 것'이지만 옵션이 테이블 외부에 있다고 가정 해 봅시다. 이 상황에서 다른 무엇을해야합니까?

복원 확인은 데이터베이스의 무결성 만 확인합니다. 백업에 악의적 인 코드가 포함되어 있는지 여부를 알려면 RESTORE VERIFYONLY가 백업 볼륨에 포함 된 데이터의 구조를 확인하지 않습니다. 회사 내부에서 백업을 수행하는 경우 악의적 일 수 있지만 타사가 제공하는 경우에는 Shawn이 지적한대로주의해야합니다.

Microsoft 온라인 설명서에 따르면

보안상의 이유로 알 수 없거나 신뢰할 수없는 출처의 데이터베이스를 연결하거나 복원하지 않는 것이 좋습니다. 이러한 데이터베이스에는 의도하지 않은 Transact-SQL 코드를 실행하거나 스키마 또는 실제 데이터베이스 구조를 수정하여 오류를 일으킬 수있는 악성 코드가 포함될 수 있습니다. 알 수 없거나 신뢰할 수없는 소스의 데이터베이스를 사용하기 전에 비 프로덕션 서버의 데이터베이스에서 DBCC CHECKDB 를 실행 하고 데이터베이스의 저장 프로 시저 또는 기타 사용자 정의 코드와 같은 코드도 검사하십시오.

이 질문은 주로 맬웨어가 포함 된 백업에 중점을 두지 만 복원 작업 자체에서 원치 않는 잠재적으로 악의적 인 동작을 얻을 수도 있습니다.

과거에 실수로 손상된 백업 파일을 복원하여 SQL Server가 백업 파일의 끝을지나 읽게하려고 시도하여 SQL Server가 충돌 할 수 있음을 발견했습니다. 어떤 버전이 취약하거나 정확하게 문제를 재현하는 데 필요한지 확실하지 않습니다. 몇 년 전에이 문제가 발생했을 때 제한된 세부 사항을 여기에 기록했습니다 .

알 수없는 출처에서 알 수없는 데이터베이스를 복원하는 위험은 무엇입니까? 없음

알 수없는 응용 프로그램이 sysadmin 계정을 사용하여 연결하여 해당 데이터베이스에 연결하고 코드 실행을 시작하면 어떤 위험이 있습니까? 많이! 응용 프로그램 계정에 데이터베이스 내 권한 만 있고 서버 수준 액세스 권한이없는 경우 실제로 데이터베이스 외부에서 할 수있는 일은 없습니다. 이것은 기본적으로 서버에 적절한 보안 프레임 워크를 설정하는 것으로 시작됩니다.

데이터베이스 백업을받은 후 이미 다른 데이터베이스를 호스팅하고있는 서버로 데이터베이스를 복원하라는 지시를 받았지만 백업에 포함 된 내용이나 소스의 신뢰 여부에 대한 유용한 정보는 제공되지 않습니다.

좋은. 귀하는 그 결과에 대해 전적으로 책임을 진다고 말한 사람에게 서명 한 서면 진술서를 요구합니다. 그들이 그렇게하지 않으려면 백업 파일을 검사 한 후 (가능한 경우) 샌드 박스에서 설치를 테스트하고 모든 테이블, 절차 등을 철저히 검사해야합니다. 어떤 시점에서 이상한 냄새가 나는 경우에는 착용하지 마십시오. 생산 시스템. 그럼에도 불구하고, 당신은 당신이 백업을 믿지 않았으며 직접 명령 하에서 만 이것을하고 있음을 분명히해야합니다 (상사와 그의 상사에게).

그들이 그러한 진술에 서명하지 않으면, 무엇이든하기 전에 상사에게 알리십시오. 전문가라면 어리석은 사람이 어떤 명령을하든 시스템을 최대한 보호해야합니다. 해고 당할 수도 있지만 머리를 높이 들고 올바른 일을했다는 것을 알 수 있습니다.

여기에 제안 된 광범위한 광범위한 위험 이외에 말 당 많은 위험이 없습니다. 언급했듯이 데이터베이스 백업 자체에 자동 실행 항목을 갖는 것은 어렵습니다. 일종의 외부 트리거링 메커니즘이 필요합니다.

라이센싱에 문제가있는 경우 오래된 랩톱 / 데스크톱과 평가판 데이터베이스 소프트웨어 (SQLExpress)를 구하십시오. 머신에서 백업 파일을 복사하고 네트워크 / 무선을 분리 한 후 복원하십시오. 그런 다음 파기를 시작하십시오. 숨길 수있는 장소가 많기 때문에 필요한 시간을 모두 가져야합니다. 대부분이 스레드의 다른 게시물로 이미 덮여 있습니다.

DBA 무결성과 프로덕션 환경의 안녕은 상급자가 제공하는 모든 주문보다 중요합니다.