Windows Azure 데이터 보안 구현 사례

기업 고객 (사실, 모든 고객) Windows http://www.aliyun.com/zixun/aggregation/13357.html 응용 프로그램을 배포 하 고 싶은 "> azure" 그들의 데이터의 보안에 대해 가장 우려. 디스크 공간을 다른 고객에 게 다시 할당할 때 새 소유자는 데이터 보호에 때때로 간과 공간을 확보 후 디스크에 원본 데이터를 읽을 수 없습니다 있는지 확인 하십시오. 극단적인 보기는 폐기 처리를 데이터 센터 드라이브에서 제거 하거나 다른 작업에 다시 사용. 발표 하기 전에 해제 된 공간을 덮어 0 또는 다른 패턴을 사용 하 여이 보장 하는 가장 쉬운 방법은 이다. 이 범위 수 크게 성능 영향을, 그래서 Azure, 마찬가지로 대부분의 시스템 사용 하 여 더 복잡 하지만 더 효율적인 메커니즘.

이 문서에서 우리는 Windows Azure 및 SQL Azure 소프트웨어는 다음과 같은 목적을 위해 하 고 밖으로 찾을 거 야: Windows Azure 가상 컴퓨터 인스턴스, Windows Azure 가상 컴퓨터 드라이브, Windows Azure 드라이브의 제거를 방지 하기 위해, 바람 OWS Azure 저장소, SQL Azure 데이터 또는 SQL Azure 인스턴스 자체 데이터 공개 또는 다른 고객에 게 고객의 데이터를 노출 합니다. 이러한 메커니즘의 내용은 다르지만 개념은 비슷한: 사용자가 이전에 기록 되지 디스크 위치에서 데이터를 읽을 수.

이 문서에서는 자세한 정보는 Windows Azure 수석 소프트웨어 엔지니어, 고유 보안 건축가 찰리 카우 프만 의해 제공 됩니다. 여기와 여기 찰리의도 서의 일부 찾을 수 있습니다. 찰리, 감사 합니다!

데이터 보호의 개념에 대 한

실제로, 디스크는 스파스 할당. 즉, 가상 디스크를 만들 때 디스크 공간의 총 크기 할당 되지 않습니다. 대신, 영역 실제 디스크에 가상 디스크에 주소를 매핑하는 테이블을 만들어야 하 고 테이블은 처음 빈. 고객 가상 디스크에 데이터를 기록 하는 처음으로 실제 디스크 공간을 할당 하 고 플래그는 테이블에 설정 됩니다. 우리는 그래프의 시리즈를 수행 하 여 개념을 이해할 수 있다:

그림 1: 사용자에 게 할당 된 데이터 블록

위의 그림 1에서 두 개의 데이터 블록의 각각 그들의 각각 쓰기 요청에 따라 두 사용자가 할당 됩니다.

그림 2: 사용자 데이터 블록 해제

위의 그림 2, 사용자 "삭제" 데이터를 데이터 블록을 무료로 합니다. 데이터 블록을 사용할 수로 표시 되 고 다른 영향을 받지 않습니다.

그림 3: 사용자에 게 최근 출시 된 데이터 블록을 할당

위의 그림 3에서 새로 해제 된 블록의 데이터와 데이터의 이전 할당된 블록 할당 했다 새로운 사용자에 대 한 쓰기 요청 하는 경우. 이전 출시 된 데이터 블록의 여전히 영향을 하지 않습니다. 기본적으로, 프로시저는 사용자 요청에 쓸 때 디스크, 그것은 새로운 데이터를 저장 하는 사용자에 할당 된 기존 디스크에 충분 한 공간이 있는지 여부를 결정 해야 합니다. 그렇다면, 새 데이터가 기존 블록에 데이터를 덮어씁니다. 그렇지 않으면, 새 데이터 블록을 할당 되 고 데이터는 새로운 블록에 기록 됩니다. 다음 그림에서이 논리를 볼 수 있습니다.

그림 4: 사용자가 디스크에 데이터를 쓰도록 요청

문제는 지금 그 고객이 다른 고객 삭제, 데이터를 읽을 수 있습니다 그리고 푸른 관리자 또한 고객 삭제 데이터를 읽을 수는. 누구 든 지 그것에 아직 기록 되지 않은 가상 디스크에 영역에서 읽을 하려고, 아니 물리적 공간 영역에 할당 되 고 데이터가 반환 됩니다. 우리는 다음 그림에는 논리와 결과 볼 수 있습니다. 블록 사용 가능한 것으로 표시 되지만 관리자 블록 하기 전에 소유자를 확인 하기 위해 모든 유틸리티를 사용할 수 없습니다 푸른 관리자만 읽을 수 있습니다.

그림 5: 사용자에 게 읽기 요청

개념적으로,이 읽기와 쓰기를 추적 하는 소프트웨어에 적용 됩니다. SQL Azure에 대 한이 SQL 소프트웨어에 의해 이루어집니다. 하늘빛 저장용이 푸른 스토리지 소프트웨어에 의해 이루어집니다. VM의 아닌 영구 드라이브에 대 한이 호스트 운영 체제의 VHD 처리 코드에 의해 이루어집니다. 클라이언트 소프트웨어에 액세스할 수 있기 때문에 가상 디스크 (가상 주소에서 물리 주소 매핑에 일어난 클라이언트 VM 외부), 읽기 또는 쓰기 실제 유휴 물리적 주소를 다른 고객에 게 할당 된 요청을 만들 수 없습니다.

참고: 경우에 따라 쓰기 로직 수정 됩니다 (그림 4 참조), 그리고 디스크에 데이터 블록을 두 번째 시간에 대 한 기록 될 때 덮어쓰지 않습니다. 대신, 새로운 블록 할당 되 고 데이터는 새로운 블록에 기록 됩니다. 오래 된 블록 사용 가능으로 표시 됩니다. 이 메서드는 종종 로그 기반 파일 시스템 이라고 합니다. 그것은 비효율적, 들릴지 모르지만이 이렇게 대부분의 데이터를 물리적 디스크를 찾을 시간을 최소화 하 고 더 나은 성능을 달성에 인접 위치에 쓸 수 있습니다. 이러한 세부 정보는 투명 하지만 고객에 게 관련 때문에 그 경우에 고객 0를 사용 하 여 명시적으로 디스크를 해제 하기 전에 가상 디스크의 각 블록을 덮어, 그것은 보증 하지 않습니다 고객의 데이터 물리적 디스크에 남아 있지 것입니다 의미.

Windows Azure 가상 컴퓨터 (VM)

VM을 삭제 후 로컬 가상 디스크의 내용을 저장 하는 디스크 공간 사용 가능으로 표시 하지만 완전 하지 않게 삭제. 공간이 결국 다른 Vm에 대 한 데이터를 저장 하는 데 사용 됩니다 하지만 콘텐츠 만료 최대 시간 디스크에 있어야 지정 하지 않습니다. 그러나, 가상화 메커니즘은 다른 고객 (또는 동일한 고객)까지 생성 되는 위협 없는 데이터 공개 데이터를 다시 작성 될 때까지 디스크에 포인트를 읽을 수 없습니다 수 있도록 설계 되었습니다. VM에 대 한 새로운 가상 디스크를 만든 후 가상 디스크 익명된 가상 디스크 영역을 읽을 때 우리가 항상 0을 반환 하기 때문에 삭제 되는 것으로 보인다. VM 인스턴스를 초기화 하는 경우 해당 하는 새 하드웨어로 이동입니다.

Windows Azure VM 드라이브와 Windows Azure 드라이브 (x 드라이브)

Windows Azure에서 VM 인스턴스를 액세스할 수 있는 가상 드라이브의 두 가지 유형이 있다. 디스크 c:, d: 디스크, 및 e: 디스크 웹 역할 및 작업자 역할에는 노드의 로컬 디스크를 계산 합니다. 이 디스크에 데이터 중복 패션에 저장 되지 않습니다 하 고 일시적인 데이터로 처리 해야 합니다. 하드웨어 오류가 발생 한 경우, VM 인스턴스를 다른 노드로 이동 하 고 가상 디스크의 내용을 초기 값으로 다시 설정 됩니다. VM 인스턴스를 초기화 하는 경우 c: 디스크, 디스크 d: 및 e: 디스크는 초기 상태로 되돌아갑니다, 새 하드웨어로 이동 하는 것과 같습니다.

Windows Azure 드라이브 ("x-드라이브" 라고도 함) Windows Azure 저장소에 Blob에 저장 됩니다. X-드라이브 지속적 이며 고객 그것을 대체 하는 명시적인 작업을 수행 하지 않으면 재설정 되지 않습니다. 이 데이터는 중복 모드에 저장 되며 하드웨어 오류가 발생 하는 경우에 손실 되지 않습니다. VM 인스턴스를 삭제 해도 관련된 x-드라이브에 있는 데이터는 삭제 되지 않습니다. Blob 자체 (또는 BLOB을 포함 하는 저장소 계정을 삭제) 삭제 x-드라이브. Windows Azure 저장소에서 데이터 삭제를 처리 하는 방법에 설명 합니다 다음 섹션을 참조.

Windows Azure 저장소 (테이블, blob, 큐)

Windows Azure 저장소 하위 시스템에서 고객 데이터 불가능 삭제 작업을 호출 합니다. 삭제를 포함 한 모든 스토리지 작업 즉시 일관성을 달성 하기 위해 설계 되었습니다. 성공적 삭제 작업 관련된 데이터 항목에 대 한 모든 참조를 삭제 하 고 스토리지 Api 통해 액세스할 수 없습니다. 삭제 된 데이터 항목의 모든 복사본은 결국 회수 됩니다. 실제 정보 (즉, 다시 초기화), 스토리지 관련된 블록 다시 사용 하는 경우 다른 데이터를 저장, 덮어씁니다 표준 컴퓨터 하드 디스크 드라이브 처럼.

SQL Azure

SQL Azure에서 삭제 된 데이터 삭제, 표시 되어 있지만 삭제 되지 않습니다. 전체 데이터베이스를 삭제 하면, 그것은의 모든 내용을 삭제 하는 것과 같습니다. 어떤 경우에, SQL Azure 구현 기본 저장소에 대 한 모든 액세스를 방지 하 여 사용 하는 데이터 손상 되지 않도록 수 (를 제외 하 고 SQL Azure API를 통해). API는 사용자가 읽기, 쓰기, 및 데이터를 삭제 하지만 이전 작성 된 데이터를 읽기 위해 사용자를 허락 하지 않을 수 있습니다.

자동 백업 및 법의학

일반적으로, 고객은 그들의 데이터는 허가 없이 액세스 하지 보장 하려고 합니다. 어떤 경우에 그들은 심지어 삭제 된 데이터는 허가 없이 액세스 하지 않도록 합니다. 일단 데이터가 삭제 되었거나 변경, 고객에 게 제공 하는 인터페이스에 의해 더 이상 검색할 수 없습니다 하지만 데이터 상당한 기간 동안 디스크에 남아 있을 수 없습니다 그리고 이론적으로 내부 법의학 도구로 복구할 수 없습니다 (하지만 삭제 된 데이터의 가능성이 시간이 지남에 감소 됩니다). 결국, 프로덕션 환경에서 제거 하는 어떤 실제 디스크 것입니다 완전히 삭제 또는 파괴.

우리는 가까운 장래에 명시적 백업을 만들 필요 없이 삭제 된 데이터 복구 (와 변경 된 데이터를 복원) 고객 수 있도록 기능을 도입 고려 하. 이러한 도구를 사용 하 여, 당신은 수 없습니다 완전히 보장 고객 그 데이터는 액세스할 수 없습니다 권한 있는 당사자에 의해 후 삭제 됩니다. 고객은 더 이상 백업 시간을 선택 하지 않는 한 이러한 도구를 제한 된 시간 내에 (더 이상 30 일) 삭제 된 데이터를 검색할 수 없습니다. 이 글을이 쓰는 당시, 14-21 일 내에서 SQL Azure 데이터베이스에서 삭제 된 데이터를 복구할 수 있는 몇 가지 오픈 도구 있다. 하늘빛 저장 또는 임시 디스크 컴퓨팅 azure 같은 도구가입니다.