격리된 스토리지

데스크톱 앱에서 격리된 스토리지는 코드와 저장된 데이터를 연결하는 표준화된 방법을 정의하여 격리와 안전을 제공하는 데이터 스토리지 메커니즘입니다. 표준화를 통해 다음과 같은 여러 가지 이점도 활용할 수 있습니다. 관리자는 파일 스토리지 구성, 보안 정책 설정, 사용하지 않은 데이터 삭제를 위해 격리된 스토리지를 조작하는 도구를 사용할 수 있습니다. 격리된 스토리지를 사용하면 더 이상 파일 시스템에서 안전한 위치를 지정하기 위해 코드에 고유 경로를 포함할 필요가 없으며 격리된 스토리지에만 액세스할 수 있는 다른 애플리케이션으로부터 데이터가 보호됩니다. 애플리케이션의 스토리지 영역 위치를 나타내는 하드 코드된 정보는 필요하지 않습니다.

데이터 구획 및 저장소

애플리케이션이 데이터를 파일에 저장할 때 스토리지 위치가 다른 애플리케이션에 알려져 손상될 가능성을 최소화할 수 있도록 파일 이름과 스토리지 위치를 신중하게 선택해야 합니다. 이러한 문제를 관리할 적절한 표준 시스템 없이 스토리지 충돌을 최소화하는 기법을 즉흥적으로 만드는 것은 복잡할 수 있으며 결과를 신뢰할 수도 없습니다.

격리된 스토리지를 사용하면 데이터는 항상 사용자와 어셈블리별로 격리됩니다. 어셈블리의 원본 또는 강력한 이름과 같은 자격 증명은 어셈블리 ID를 결정합니다. 또한 유사한 자격 증명을 사용하여 데이터가 애플리케이션 도메인별로 격리될 수도 있습니다.

격리된 스토리지를 사용하는 경우, 애플리케이션은 게시자 또는 서명 등과 같은 코드 ID의 몇 가지 측면과 관련된 고유 데이터 구획에 데이터를 저장합니다. 데이터 컴파트먼트는 특정 스토리지 위치가 아니라 추상적인 개념이며 스토리지라고 하는 하나 이상의 격리된 스토리지 파일로 구성됩니다. 이 스토리지는 데이터가 저장되는 실제 디렉터리 위치를 포함합니다. 예를 들어, 애플리케이션은 관련된 데이터 구획을 가질 수 있고 파일 시스템의 디렉터리는 이 애플리케이션의 데이터를 실제로 유지하는 저장소를 구현할 수 있습니다. 저장소에 저장된 데이터는 사용자 기본 설정 정보에서 애플리케이션 상태에 이르기까지 모든 종류의 데이터가 될 수 있습니다. 개발자의 경우, 데이터 구획의 위치는 투명합니다. 저장소는 보통 클라이언트에 있지만, 서버 애플리케이션은 사용자를 대신하여 관련 기능을 수행하면서 그 사용자를 가장하여 정보를 저장하는 격리된 저장소를 사용할 수 있습니다. 또한 격리된 스토리지는 로밍 사용자와 함께 정보가 이동되도록 사용자의 로밍 프로필과 함께 서버의 정보를 저장할 수 있습니다.

격리된 스토리지의 할당량

할당 한도는 사용 가능한 격리된 스토리지 크기의 제한 값입니다. 디렉터리 및 저장소의 다른 정보와 관련된 오버헤드는 물론 파일 공간(바이트)을 포함합니다. 격리된 스토리지는 IsolatedStoragePermission 개체를 사용하여 설정된 스토리지의 제한에 해당하는 사용 권한 할당을 사용합니다. 할당량을 초과하는 데이터를 쓰려고 하면 IsolatedStorageException 예외가 throw됩니다. .NET Framework 구성 도구(Mscorcfg.msc)를 사용하여 수정할 수 있는 보안 정책에 따라 코드에 부여될 권한이 결정됩니다. IsolatedStoragePermission 권한이 부여된 코드는 UserQuota 속성이 허용하는 수준의 스토리지만 사용하도록 제한됩니다. 그러나 코드에서 다른 사용자 ID를 제공하여 사용 권한 할당 한도를 무시할 수 있으므로 사용 권한 할당 한도는 코드 동작에 대해 고정된 제한이 아니라 코드 동작 방식에 대한 지침으로 사용됩니다.

로밍 저장소에는 할당 한도가 적용되지 않기 때문에 코드에 약간 높은 수준의 사용 권한이 있어야 이를 사용할 수 있습니다. 열거형 값 AssemblyIsolationByRoamingUser 및 DomainIsolationByRoamingUser는 로밍 사용자를 위한 격리된 스토리지를 사용하여 권한을 지정합니다.

액세스 보안

격리된 스토리지를 사용하면 부분적으로 신뢰할 수 있는 애플리케이션은 컴퓨터의 보안 정책에 의해 제어되는 방식으로 데이터를 저장할 수 있습니다. 이 방법은 특히 사용자가 주의하여 실행해야 하는 다운로드된 구성 요소에 유용합니다. 표준 I/O 메커니즘을 사용하여 파일 시스템에 액세스하는 경우, 사용 권한을 이 유형의 코드에 부여하는 경우는 거의 없습니다. 그러나 격리된 스토리지를 사용할 권한은 로컬 컴퓨터, 로컬 네트워크 또는 인터넷에서 실행되는 코드에 기본적으로 부여됩니다.

관리자는 해당 신뢰 수준에 따라 애플리케이션 또는 사용자가 가질 수 있는 격리된 스토리지 양을 제한할 수 있습니다. 또한 사용자의 지속된 데이터를 모두 제거할 수도 있습니다. 격리된 스토리지를 만들거나 액세스하려면 코드에 적절한 IsolatedStorageFilePermission 권한이 부여되어야 합니다.

격리된 스토리지에 액세스하려면 필요한 네이티브 플랫폼 운영 체제 권한이 모두 코드에 있어야 합니다. 파일 시스템을 사용할 수 있는 권한을 가진 사용자를 제어하는 ACL(액세스 제어 목록)이 충족되어야 합니다. .NET 애플리케이션은 특정 플랫폼 관련 가장을 수행하는 경우를 제외하고는 격리된 스토리지에 액세스할 수 있는 운영 체제 권한을 이미 가지고 있습니다. 이런 경우 애플리케이션은 가장된 사용자 ID가 격리된 스토리지에 액세스할 수 있는 적절한 운영 체제 권한을 가지고 있는지 확인해야 합니다. 이 액세스 권한은 웹에서 실행되거나 다운로드된 코드에 특정 사용자와 관련된 스토리지 영역에서 읽고 쓸 수 있는 편리한 방법을 제공합니다.

격리된 스토리지에 대한 액세스를 제어하기 위해 공용 언어 런타임은 IsolatedStorageFilePermission 개체를 사용합니다. 각 개체에는 다음과 같은 값을 지정하는 속성이 있습니다.

• 허용 수준 - 허용된 액세스 형식을 나타내며 값은 IsolatedStorageContainment 열거형의 멤버입니다. 이러한 값에 대한 자세한 내용은 다음 섹션의 표를 참조하세요.

• 이전 섹션에서 설명한 스토리지 할당량입니다.

런타임은 코드에서 처음으로 저장소를 열려고 할 때 이 IsolatedStorageFilePermission 권한을 요청합니다. 코드의 신뢰 정도에 따라 이 권한을 부여할지 여부를 결정합니다. 이 사용 권한이 부여되면 보안 정책 및 코드의 IsolatedStorageFilePermission 요청에 의해 허용되는 사용법과 스토리지 할당량 값이 결정됩니다. 보안 정책은 .NET Framework 구성 도구(Mscorcfg.msc)를 사용하여 설정됩니다. 호출 스택의 모든 호출자를 검사하여 각 호출자가 적절한 최소 허용 수준 값을 가지고 있는지 확인합니다. 또한 런타임은 파일을 저장할 저장소를 열거나 만든 코드에 부과된 할당 한도도 검사합니다. 이러한 조건을 충족하면 사용 권한이 부여됩니다. 할당 한도는 파일을 저장소에 쓸 때마다 다시 검사됩니다.

공용 언어 런타임은 보안 정책을 기반으로 적절한 모든 IsolatedStorageFilePermission 을 부여하므로 권한을 요청하는 데 애플리케이션 코드가 필요하지 않습니다. 그러나 IsolatedStorageFilePermission을 포함하여 애플리케이션에서 필요로 하는 특정 사용 권한을 요청해야 하는 경우가 있습니다.

허용 수준과 보안 위험

IsolatedStorageFilePermission에 의해 지정되는 허용 사용법에 따라 코드에서 격리된 스토리지를 만들고 사용할 수 있는 정도가 결정됩니다. 다음 표에서는 사용 권한에 지정된 허용 수준이 어떤 방식으로 격리 유형에 부합하는지를 보여 주고 각 허용 수준과 관련된 보안 위험을 요약하여 설명합니다.

신뢰할 수 없는 데이터와 관련하여 격리된 스토리지 구성 요소의 안전

이 섹션은 다음과 같은 프레임워크에 적용됩니다.

• .NET Framework(모든 버전)
• .NET Core 2.1 이상
• .NET 5 이상

.NET Framework 및 .NET Core는 사용자, 애플리케이션 또는 구성 요소의 데이터를 유지하는 메커니즘으로 격리된 스토리지를 제공합니다. 기본적으로 이 레거시 구성 요소는 지금은 사용되지 않는 코드 액세스 보안 시나리오를 위해 설계되었습니다.

다양한 격리된 스토리지 API 및 도구를 사용하여 신뢰 경계 전반에서 데이터를 읽을 수 있습니다. 예를 들어 머신 전체 범위에서 데이터를 읽으면 머신에서 신뢰할 수 없는 다른 사용자 계정의 데이터를 집계할 수 있습니다. 머신 전체의 격리된 스토리지 범위에서 읽는 구성 요소 또는 애플리케이션은 이 데이터를 읽을 때의 결과를 알고 있어야 합니다.

머신 전체 범위에서 읽을 수 있는 보안 관련 API

다음 API를 호출하는 구성 요소 또는 애플리케이션은 머신 전체 범위에서 읽습니다.

• IsolatedStorageFile.GetEnumerator - IsolatedStorageScope.Machine 플래그를 포함하는 범위를 전달합니다.
• IsolatedStorageFile.GetMachineStoreForApplication
• IsolatedStorageFile.GetMachineStoreForAssembly
• IsolatedStorageFile.GetMachineStoreForDomain
• IsolatedStorageFile.GetStore - IsolatedStorageScope.Machine 플래그를 포함하는 범위를 전달합니다.
• IsolatedStorageFile.Remove - IsolatedStorageScope.Machine 플래그를 포함하는 범위를 전달합니다.

격리된 스토리지 도구 storeadm.exe는 다음 코드에서처럼 /machine 스위치를 사용하여 호출되는 경우 영향을 받습니다.

storeadm.exe /machine [any-other-switches]

격리된 스토리지 도구는 Visual Studio 및 .NET Framework SDK의 일부로 제공됩니다.

애플리케이션에서 위의 API를 호출하지 않거나 워크플로에서 이러한 방식으로 storeadm.exe를 호출하지 않는 경우에는 이 문서의 내용이 적용되지 않습니다.

다중 사용자 환경에 미치는 영향

앞에서 언급했듯이 이러한 API가 보안에 미치는 영향은 한 신뢰 환경에서 기록된 데이터를 다른 신뢰 환경에서 읽기 때문에 발생합니다. 격리된 스토리지는 일반적으로 다음 세 위치 중 하나를 사용하여 데이터를 읽고 씁니다.

1. %LOCALAPPDATA%\IsolatedStorage\: 예를 들어 User 범위의 경우 C:\Users\<username>\AppData\Local\IsolatedStorage\입니다.
2. %APPDATA%\IsolatedStorage\: 예를 들어 User|Roaming 범위의 경우 C:\Users\<username>\AppData\Roaming\IsolatedStorage\입니다.
3. %PROGRAMDATA%\IsolatedStorage\: 예를 들어 Machine 범위의 경우 C:\ProgramData\IsolatedStorage\입니다.

처음 두 위치는 사용자별로 격리됩니다. Windows에서는 같은 머신의 여러 사용자 계정이 서로의 사용자 프로필 폴더에 액세스할 수 없도록 합니다. User 또는 User|Roaming 저장소를 사용하는 서로 다른 두 사용자 계정은 서로의 데이터를 볼 수 없고 조작할 수 없습니다.

세 번째 위치는 머신의 모든 사용자 계정 간에 공유됩니다. 다른 계정이 이 위치에서 읽고 위치에 쓸 수 있으며 서로의 데이터를 볼 수 있습니다.

앞의 경로는 사용 중인 Windows 버전에 따라 다를 수 있습니다.

이제 두 명의 등록된 사용자 Mallory 및 Bob이 있는 다중 사용자 시스템을 살펴봅니다. Mallory는 자신의 사용자 프로필 디렉터리 C:\Users\Mallory\에 액세스할 수 있고 공유 머신 전체 스토리지 위치 C:\ProgramData\IsolatedStorage\에 액세스할 수 있습니다. Bob의 사용자 프로필 디렉터리 C:\Users\Bob\에는 액세스할 수 없습니다.

Mallory가 Bob을 공격하려는 경우 머신 전체 스토리지 위치에 데이터를 쓴 다음 Bob이 머신 전체 저장소에서 읽도록 영향을 주려고 할 수 있습니다. Bob이 이 저장소에서 읽는 앱을 실행하면 해당 앱은 Mallory가 여기에 저장한 데이터를 사용하지만 Bob의 사용자 계정 컨텍스트 내에서 작동합니다. 이 문서의 나머지 부분에서는 다양한 공격 벡터와 이러한 공격의 위험을 최소화하기 위해 앱에서 수행할 수 있는 단계를 고려합니다.

권한 상승

권한 상승 공격은 Bob의 앱이 Mallory의 파일을 읽고 자동으로 해당 페이로드의 콘텐츠를 기반으로 작업을 수행하려고 할 때 발생합니다. 머신 전체 저장소에서 시작 스크립트의 콘텐츠를 읽고 해당 콘텐츠를 Process.Start에 전달하는 앱이 있다고 가정해 보세요. Mallory가 머신 전체 저장소 내에 악성 스크립트를 저장할 수 있는 경우 Bob이 앱을 시작하면 다음이 발생합니다.

• 앱이 ‘Bob의 사용자 프로필 컨텍스트에서’ Mallory의 악성 스크립트를 구문 분석하고 시작합니다.
• Mallory가 로컬 머신에서 Bob의 계정에 액세스합니다.

서비스 거부

서비스 거부 공격은 Bob의 앱이 Mallory의 파일을 읽고 크래시되거나 제대로 작동하지 않을 때 발생합니다. 앞에서 언급한 앱이 머신 전체 저장소에서 시작 스크립트를 구문 분석하려고 시도한다고 가정해 보세요. Mallory가 머신 전체 저장소 내에서 잘 구성되지 않은 콘텐츠가 포함된 파일을 저장할 수 있는 경우 다음을 수행할 수 있습니다.

• Bob의 앱이 시작 경로의 초기에 예외를 throw하도록 합니다.
• 앱이 예외 때문에 제대로 시작되지 않게 합니다.

그런 다음 자신의 사용자 계정에서 Bob이 앱을 시작할 수 있는 기능을 거부했습니다.

정보 공개

정보 공개 공격은 Mallory가 Bob을 속여 정상적으로는 액세스할 수 없는 파일의 콘텐츠를 공개하도록 할 수 있는 경우 발생합니다. Bob의 비밀 파일 C:\Users\Bob\secret.txt를 Mallory가 읽고 싶어한다고 가정해 보겠습니다. Mallory는 파일의 경로는 알지만 Windows에서 Bob의 사용자 프로필 디렉터리에 액세스하지 못하게 하므로 파일을 읽을 수 없습니다.

대신, Mallory는 하드 링크를 머신 전체 저장소에 배치합니다. 이 특수한 종류의 파일은 자체에 콘텐츠를 포함하지는 않고 디스크의 다른 파일을 가리킵니다. 하드 링크 파일을 읽으려고 하면 대신 링크의 대상으로 지정된 파일의 콘텐츠를 읽습니다. 하드 링크를 만든 후에도 Mallory는 링크의 대상(C:\Users\Bob\secret.txt)에 액세스할 수 없으므로 파일 콘텐츠를 읽을 수 없습니다. 그러나 Bob은 이 파일에 액세스할 수 ‘있습니다’.

Bob의 앱이 머신 전체 저장소에서 읽을 때 이제 secret.txt 파일 자체가 머신 전체 저장소에 있었던 것처럼 파일 콘텐츠를 실수로 읽습니다. Bob의 앱이 종료될 때 파일을 머신 전체 저장소에 다시 저장하려고 하는 경우 파일의 실제 복사본을 *C:\ProgramData\IsolatedStorage* 디렉터리에 저장하게 됩니다. 이 디렉터리는 머신의 모든 사용자가 읽을 수 있으므로 이제 Mallory는 파일의 콘텐츠를 읽을 수 있습니다.

이러한 공격으로부터 방어하기 위한 모범 사례

중요: 환경에 상호 신뢰할 수 없는 사용자가 여러 명 있는 경우 API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine)를 호출하거나 도구 storeadm.exe /machine /list를 호출하면 안 됩니다. 둘은 모두 신뢰할 수 있는 데이터에서 작동하고 있다고 가정합니다. 공격자가 머신 전체 저장소에 악성 페이로드를 시드할 수 있는 경우 해당 페이로드로 인해 이러한 명령을 실행하는 사용자의 컨텍스트에서 권한 상승 공격이 발생할 수 있습니다.

다중 사용자 환경에서 운영하는 경우 머신 범위를 대상으로 하는 격리된 스토리지 기능을 사용하는 것을 다시 고려하세요. 앱이 머신 전체 위치에서 데이터를 읽어야 하는 경우 관리자 계정만 쓸 수 있는 위치에서 데이터를 읽는 것이 좋습니다. %PROGRAMFILES% 디렉터리 및 HKLM 레지스트리 하이브는 관리자만 쓸 수 있고 모든 사용자가 읽을 수 있는 위치의 예입니다. 따라서 해당 위치에서 읽은 데이터는 신뢰할 수 있다고 간주합니다.

앱이 다중 사용자 환경에서 ‘머신’ 범위를 사용해야 하는 경우에는 머신 전체 저장소에서 읽은 모든 파일의 콘텐츠를 유효성 검사하세요. 앱이 이러한 파일에서 개체 그래프를 역직렬화하는 경우 BinaryFormatter 또는 NetDataContractSerializer와 같이 위험한 직렬 변환기 대신 XmlSerializer와 같은 더 안전한 직렬 변환기를 사용하세요. 파일 콘텐츠에 따라 리소스 할당을 수행하는 개체 그래프나 많이 중첩된 개체 그래프는 주의해서 사용하세요.

격리된 스토리지 위치

때때로 운영 체제의 파일 시스템을 사용하여 격리된 스토리지에 대한 변경 내용을 확인하면 도움이 됩니다. 또한 개발자는 격리된 스토리지 파일의 위치를 알고 싶을 때가 있습니다. 이 위치는 운영 체제에 따라 다릅니다. 다음 표에서는 일반적으로 사용되는 몇 가지 운영 체제에서 격리된 스토리지가 만들어지는 루트 위치를 보여 줍니다. 이 루트 위치 아래에 있는 Microsoft\IsolatedStorage 디렉터리를 찾으세요. 파일 시스템에서 격리된 스토리지를 보려면 숨김 파일과 폴더를 표시하도록 폴더 설정을 변경해야 합니다.

격리된 스토리지 만들기, 열거 및 삭제

.NET에서는 System.IO.IsolatedStorage 네임스페이스의 세 가지 클래스를 제공해 격리된 스토리지와 관련된 작업을 수행할 수 있도록 해줍니다.

• IsolatedStorageFile에서 파생되는 System.IO.IsolatedStorage.IsolatedStorage 은 저장된 어셈블리 및 애플리케이션 파일의 기본 관리를 제공합니다. IsolatedStorageFile 클래스 인스턴스는 파일 시스템에 있는 단일 저장소를 나타냅니다.

• IsolatedStorageFileStream 에서 파생되는 System.IO.FileStream 은 저장소에 있는 파일에 대한 액세스를 제공합니다.

• IsolatedStorageScope 은 적절한 격리 유형을 사용하여 저장소를 만들고 선택할 수 있도록 하는 열거형입니다.

격리된 스토리지 클래스를 사용하여 격리된 스토리지를 만들고 열거하고 삭제할 수 있습니다. 이러한 작업을 수행하는 데 필요한 메서드는 IsolatedStorageFile 개체를 통해 사용할 수 있습니다. 일부 작업을 수행하려면 격리된 스토리지를 관리할 수 있는 권한을 나타내는 IsolatedStorageFilePermission 권한을 가져야 하며 파일이나 디렉터리에 액세스할 수 있는 운영 체제 권한도 가지고 있어야 합니다.

일반적인 격리된 스토리지 작업을 보여 주는 일련의 예제는 관련 항목에 나열되어 있는 방법 항목을 참조하세요.

격리된 스토리지 시나리오

격리된 스토리지는 다음 네 가지 시나리오를 비롯하여 다양한 상황에서 유용합니다.

• 다운로드된 컨트롤. 인터넷에서 다운로드된 관리 코드 컨트롤은 일반 I/O 클래스를 통해 하드 드라이브에 쓸 수 없지만 격리된 스토리지를 사용하여 사용자 설정 및 애플리케이션 상태를 유지할 수 있습니다.

• 공유 구성 요소 스토리지. 애플리케이션 간에 공유되는 구성 요소는 격리된 스토리지를 사용하여 데이터 스토리지에 대한 제어된 액세스를 제공할 수 있습니다.

• 서버 스토리지. 서버 애플리케이션은 격리된 스토리지를 사용하여 애플리케이션을 요청하는 다수의 사용자에게 개별 스토리지를 제공할 수 있습니다. 격리된 스토리지는 항상 사용자별로 분리되어 있으므로 서버는 요청하는 사용자를 가장해야 합니다. 이런 경우 데이터는 사용자를 구분하기 위해 애플리케이션에서 사용하는 동일한 ID인 보안 주체 ID를 기반으로 격리됩니다.

• 로밍. 또한 애플리케이션에서는 격리된 스토리지를 사용하여 로밍 사용자 프로필을 저장할 수 있습니다. 따라서 사용자의 격리된 저장소는 프로필을 로밍하는 데 사용됩니다.

다음과 같은 경우 격리된 스토리지를 사용하지 마세요.

• 격리된 스토리지는 충분히 신뢰할 수 있는 코드, 비관리 코드 또는 컴퓨터에서 신뢰할 수 있는 사용자로부터 보호되지 않으므로 암호화되지 않은 키 또는 암호 등의 상위 값 비밀을 저장하는 데 사용하지 마세요.

• 코드를 저장하는 데 사용하지 마세요.

• 관리자가 컨트롤하는 구성 및 배포 설정을 저장하는 데 사용하지 마세요. 사용자 기본 설정은 관리자가 제어하지 않으므로 구성 설정으로 간주되지 않습니다.

대부분의 애플리케이션은 데이터베이스를 사용하여 데이터를 저장하고 격리합니다. 이때 데이터베이스에 있는 하나 이상의 행은 특정 사용자에 대한 스토리지를 나타낼 수 있습니다. 사용자 수가 적은 경우, 데이터베이스 사용에 따른 오버헤드가 의미가 있는 경우 또는 데이터베이스 기능이 없는 경우 데이터베이스 대신 격리된 스토리지를 사용하도록 선택할 수 있습니다. 또한 데이터베이스에서 제공하는 행보다 더 융통성 있고 복잡한 스토리지가 애플리케이션에 필요한 경우에도 격리된 스토리지를 사용할 수 있습니다.

관련 문서

참조

• System.IO.IsolatedStorage.IsolatedStorage

• System.IO.IsolatedStorage.IsolatedStorageFile

• System.IO.IsolatedStorage.IsolatedStorageFileStream

• System.IO.IsolatedStorage.IsolatedStorageScope