기술 지원 시 파일 변조 또는 손상 되어 골치 아픈 경우가 간혹 발생 합니다.
- 고객사 지원을 위해 파일을 반입하는 경우 CD 손상으로 인한 파일 손상
- 보안 프로그램(DRM,EFS)에 의한 파일 변조
- 네트워크를 통한 파일 전송 시 파일 손상
파일 변조 또는 손상이 발생하면, 파일 크기가 크게 변하지 않으며 정합성 여부를 명확하게 확인 할 수 없습니다.
이로 인해 기술 지원 시 뭐가 문제인지 당황스러울 때가 있는데요.
이와 같은 상황에서 불필요한 시간 발생을 최소화 할 수 있는 방법에 대해 기술 하였습니다.
무결성 검사
파일이 변조 되어 있지 않다는 검사를 하기 위해 여러가지 방법들이 있습니다만, 가장 효율적이고 쉬운 방법을 소개하겠습니다.
md5 (MD5 128비트 해쉬 암호화 함수)툴은 Windows, Linux, OS X 등 많은 시스템에서 기본적으로 설치 되어 있습니다.
참고 자료
- MD5-위키백과 : https://ko.wikipedia.org/wiki/MD5
- 암호화 해쉬 함수-위키백과 : https://ko.wikipedia.org/wiki/%EC%95%94%ED%98%B8%ED%99%94_%ED%95%B4%EC%8B%9C_%ED%95%A8%EC%88%98
사용 방법
Windows
Linux, OS X
정상적으로 다운 받은 파일의 MD5 해쉬 값은 f1fca41add6d3054dfb2a2f8a9e19617 CUBRID-10.2-latest-Linux.x86_64.sh
(파일 사이즈 : 86903517 byte)
원본 파일에 특정 문자 삭제 후 구한 MD5 해쉬 값은 aa06214176b8bb6c93ed7ecd72e5e561 CUBRID-10.2-latest-Linux.x86_64.sh
(파일 사이즈 : 86903519 byte)
위의 결과 값을 보면, 정상적인 파일에서 약간의 수정이 발생 하더라도 해쉬값이 크게 변화하게 됩니다.
어떤 경우 사용하면 될까 ?
[ 업무 고도화 진행에 따른 운영 서버 데이터 베이스를 개발 서버에 구축 ]
1. 운영 서버 데이터 베이스 백업을 수행하여, 사용자 PC에 파일을 내려 받아, 개발 서버에 전송 하였습니다.
2. 개발 서버에 전송 받은 백업 볼륨(demodb_bk0v000)을 통해 복구 수행.
3. 복구 수행 시 아래와 같은 에러가 발생하며, restoredb 에러 로그를 확인하니 백업 볼륨이 아니라는 로그가 기록(./demodb_bk0v000 is not a backup volume.) 됩니다.
4. 운영 서버에서 개발 서버까지 백업 볼륨을 이동하는데 어느 구간에서 손상이 됬는지 확인이 필요한 상황으로
파일 전송 오류로 판단하여, 파일을 재전송 하였습니다.
5. 재전송하였지만 동일한 문제가 발생하였고, 사용자 PC의 EFS 툴로 인하여, 백업 볼륨이 암호화 된 것으로 확인 되었습니다.
- 진행 당시 암호화 툴은 문서파일만 암호화 한다는 내용을 확인 했는데.....
6. 결국 사용자 PC의 암호화 툴 예외처리를 진행하고서 작업 완료가 되었습니다.
- 실제 작업 당시 총 12개의 백업 볼륨, 총 사이즈 3TB
- 운영 서버에서 개발 서버까지 백업 볼륨 12개를 옮기는데 약 15시간 소요.
- 백업 볼륨 손상이 3회 발생하였으며, 실제 복구 작업에 걸린 시간은 4일 소요.
- 작은 파일을 옮기는 경우 손상이 발생하더라도 재전송하며 문제를 찾으면 되지만, 대용량 파일을 다루는 상황에는 많은 시간이 소요 됩니다.
- 대용량 파일을 이용한 작업을 할 경우 원본 파일과 작업 파일의 정합성을 위해 checksum을 구하는 해쉬 함수를 사용하여 진행 하는 것이 불필요한 시간 소요가 발생 하지 않습니다.
[ 신규 CUBRID 설치 건으로 테스트용 설치 버전 반입 ]
1. 고객사에서 요청한 CUBRID 설치 버전을 CD에 담아 반입
2. 고객사 PC에 CD 마운트 후 설치 버전을 내려받아 설치 진행
3. 설치 진행 중 아래와 같은 오류 발생
4. 고객사 PC 설치 파일 checksum 해쉬 값 확인
5. 원본 파일과 CD의 파일의 해쉬값과 고객사 PC 설치 파일의 해쉬값이 다른 것을 확인
6. 고객사 PC EFS 암호화 툴의 정책 오류로 발생한 문제
7. 암호화 툴 예외처리 후 정상적으로 설치 진행 및 완료
- 설치 문제에 대해 CUBRID의 버그가 아니냐 라는 고객의 질문에 정확한 답을 내놓지 못할 수가 있습니다.
- 고객사 방문 전 원본 파일의 hash값, CD에 담은 파일의 hash값을 모두 확인해 놓은 상태로 고객사 PC에서 문제가 발생한 것에 대해 답을 했으며, 억울한... 누명?을 벗게 됬었네요.
해쉬값을 구하는데 소요되는 비용 ?
파일 사이즈가 수 GB 단위 까지는 해쉬 값이 금방 구해집니다. (싱글쓰레드로 수행 됩니다.)
파일 사이즈가 수십 GB 단위를 넘어가면 해쉬 값을 구하는 시간 소요가 수십분 발생 합니다.
해쉬 값을 구하는 시간을 불필요하지 않다 생각해야하며, 위 문제와 같은 상황이 발생할 여지가 있다면, 꼭 해쉬값을 구해 파일의 정합성을 확인하여 진행하는것이 좋습니다.
위와 같은 상황에서는 암호화를 위한 것이 아닌 파일의 정합성을 위한 것이므로 MD5 해쉬값 충돌을 보완한 sha1, sha2, sha3의 함수를 사용할 필요는 없습니다.
속도면에서 좋은 MD5를 활용하는것이 좋으며, OS에 기본적으로 탑재 되어 있어 별도의 설치가 필요 없습니다.
해쉬 알고리즘 속도 비교 - https://zetawiki.com/wiki/%ED%95%B4%EC%8B%9C_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98_%EC%86%8D%EB%8F%84_%EB%B9%84%EA%B5%90
마치며
많은 소프트웨어 미러사이트에서 업로드한 파일의 checksum 해쉬 값을 제공합니다.
(사이트 별로 MD5, sha1,sha2 해쉬 함수 방식이 다르며, MD5가 가장 많이 사용 됨)
미러 사이트에서 원본에 대한 checksum 해쉬 값을 확인하여, 불필요한 소요 시간 없는 작업이 되길 바랍니다.
데이터 베이스 접근 제어와 CUBRID
[CUBRID inside] Query Process란?
