게임이나 앱에서 에셋 번들을 배포하거나 게임이나 앱으로 원격 서버에서 다운로드할 수 있습니다. 후자의 경우, 에셋 번들을 다운로드할 때 에셋 번들 데이터 손상과 악의적인 행위자의 공격을 방지하기 위한 예방 조치를 취하는 것이 중요합니다. 사용자 기기에 발생하는 알 수 없는 크래시의 일반적인 원인은 다운로드한 에셋 번들의 데이터 손상입니다. 이러한 상황은 진단하고 해결하는 데 많은 노력이 소요될 수 있습니다. 또한 에셋 번들에는 실행 코드가 포함될 수 없지만 직렬화된 데이터를 변경하면 공격자가 게임 코드나 Unity 런타임의 취약점을 활용할 수 있습니다.
UnityWebRequestAssetBundle을 사용하여 인터넷에서 에셋 번들을 다운로드하고 캐시할 수 있습니다. 이 API를 사용하는 경우 URL이 동일한 컴퓨터에서 실행되는 로컬 웹 서버를 참조하지 않는 한 URL에서 HTTPS 프로토콜을 사용해야 합니다. HTTP 프로토콜은 안전하지 않으며 악의적인 중간자 공격에 취약합니다.
Unity는 체크섬을 사용하여 에셋 번들을 다운로드할 때 에셋 번들이 손상되거나 수정되지 않았는지 확인할 수 있는 툴을 제공합니다. 32비트 체크섬은 에셋 번들 빌드 프로세스 중에 생성되고 .manifest 파일에 기록되고 BuildPipeline.GetCRCForAssetBundle에 의해 노출됩니다. CRC 검사를 사용하면 에셋 번들 데이터가 빌드된 후 손상되거나 조작되지 않았는지 확인합니다. 잘못된 에셋 번들 콘텐츠가 캐시에 넣을 수 없도록 UnityWebRequestAssetBundle.GetAssetBundle을 통해 에셋 번들을 다운로드할 때 이 CRC를 제공해야 합니다. 자세한 내용은 에셋 번들 압축 및 캐싱을 참조하십시오.
에셋 번들을 직접 다운로드하거나 배포하고 빌트인 에셋 번들 캐시를 사용하지 않는 경우, 가져온 콘텐츠를 사용하기 전에 무결성 검사를 수행해야 합니다. 이를 위한 한 가지 방법은 AssetBundle Load API의 선택적 파라미터를 사용하여 예상 CRC 값을 전달하는 것입니다. 제공되는 경우, 로딩 시스템은 에셋 번들을 로드하기 전에 압축되지 않은 에셋 번들 콘텐츠의 체크섬을 계산합니다. 에셋 번들의 CRC가 제공된 CRC와 일치하지 않으면 에셋 번들이 로드되지 않습니다. LZ4로 압축된 에셋 번들의 경우 파일을 RAM으로 완전히 압축 해제해야 하므로 비용이 많이 들 수 있습니다. LZMA 압축 에셋 번들의 경우 로드로 인해 이미 전체 콘텐츠가 압축 해제되므로 CRC 검사를 수행하는 것은 큰 추가 비용이 들지 않습니다. 전체적으로 파일을 가져와 기기에 저장할 때 무결성 검사를 한 번만 수행하면 CRC 계산 비용을 줄일 수 있으므로 로드할 때마다 반복하는 것보다 실용적일 수 있습니다.
참고: 에셋 번들 압축을 사용하는 경우 다른 일반적인 해시 알고리즘(예: md5)을 사용하여 에셋 번들 파일을 확인해서는 안 됩니다. 콘텐츠가 변경되지 않았더라도 Unity가 에셋 번들을 다시 압축하므로 실제로 유효한 파일 콘텐츠가 있는 경우에도 파일 콘텐츠 해시가 변경될 수 있기 때문입니다. 반대로 에셋 번들의 CRC 값은 압축되지 않은 콘텐츠로부터 계산되며, 이 콘텐츠는 번들이 다시 압축될 때도 일정합니다.
참고: Unity 빌드가 계산하고 .manifest 내에 저장하는 에셋 번들 해시는 에셋 번들의 전체 파일 콘텐츠의 해시가 아닙니다. 에셋 번들의 버전 값으로 사용할 수 있지만 파일 손상 검사에는 적합하지 않습니다.
사용자가 다른 플레이어에게 배포되는 콘텐츠(사용자 생성 콘텐츠)를 업로드하도록 허용하는 경우 부적절하거나 악의적인 콘텐츠를 필터링하는 것은 본인의 책임입니다. 사용자가 바이너리 에셋 번들 파일을 빌드하고 업로드하도록 허용하지 않는 것이 좋습니다. 사용자가 소스 에셋을 업로드하고 개발자가 에셋 번들 바이너리 파일을 빌드하도록 하는 것이 좋습니다. 이렇게 하면 수동 및 자동화된 프로세스를 통해 악의적이거나 부적절한 콘텐츠를 더 쉽게 필터링할 수 있습니다. 또한 이후 Unity 버전으로 업그레이드하는 경우 필요에 따라 에셋 번들을 다시 빌드할 수도 있습니다.