어셈블리 (CLI)

3. 어셈블리 이름

어셈블리의 이름은 다음 네 부분으로 구성된다.

• 짧은 이름: Windows 환경에서는 확장자를 제외한 PE 파일의 이름이다.
• 문화권: 어셈블리의 로케일을 나타내는 RFC 1766 식별자이다. 일반적으로 라이브러리 및 프로세스 어셈블리는 문화권 중립적으로 설정하며, 이 정보는 주로 위성 어셈블리에 사용된다.
• 버전: 주요(Major), 부(Minor), 빌드(Build), 수정(Revision)의 네 부분으로 구성되며 점(`.`)으로 구분되는 버전 번호이다.
• 공개 키 토큰: 어셈블리를 디지털 서명^[1]하는 데 사용된 개인 키에 해당하는 공개 키의 64비트 해시 값이다. 이렇게 서명된 어셈블리는 강력한 이름을 가진다고 한다.

4. 어셈블리 버전 관리

CLI 어셈블리는 버전 정보를 포함하여 공유 어셈블리 사용 시 발생할 수 있는 응용 프로그램 간의 충돌 문제를 상당 부분 해결할 수 있다.^[5][2] 하지만 모든 잠재적인 버전 충돌을 완전히 제거하지는 못한다.^[6][3]

어셈블리의 버전 정보는 네 부분으로 구성된 번호를 사용하며, 각 부분은 점(`.`)으로 구분된다. 형식은 다음과 같다.

`MajorVersion.MinorVersion.BuildNumber.Revision`

이 버전 정보는 어셈블리 이름의 일부로 관리된다. 어셈블리 이름은 다음과 같은 네 가지 요소로 구성된다.

공개 키 토큰은 서로 다른 개발자가 만든 어셈블리가 우연히 같은 약식 이름을 갖더라도 .NET 환경이 이를 구별할 수 있게 해준다. 하지만 Windows의 파일 시스템은 파일 이름만을 기준으로 파일을 관리하기 때문에, 약식 이름이 같은 여러 버전의 어셈블리를 같은 폴더에 둘 수 없는 문제가 있다.

이 문제를 해결하기 위해 .NET은 글로벌 어셈블리 캐시(GAC, Global Assembly Cache)라는 특별한 저장소를 제공한다. GAC는 시스템 전체에서 공유되는 어셈블리들을 위한 중앙 저장소 역할을 하며, 동일한 약식 이름을 가진 여러 버전의 어셈블리나 서로 다른 컬처를 가진 어셈블리들을 함께 관리할 수 있게 해준다. CLR(Common Language Runtime)은 GAC에 등록된 어셈블리들을 마치 하나의 폴더에 있는 것처럼 인식하고 로드할 수 있다.

또한, 어셈블리 위조 공격을 방지하기 위해 어셈블리는 개발자의 비밀 키로 서명된다. 서명 과정에서는 어셈블리의 중요 내용에 대한 해시값을 계산하고 이를 비밀 키로 암호화한다. 이 암호화된 해시값과 공개 키는 어셈블리 파일 내에 함께 저장된다. CLR이 엄격한 이름(strong name)을 가진 어셈블리를 로드할 때는, 저장된 공개 키를 사용하여 암호화된 해시를 복호화하고, 이를 실제 어셈블리 내용의 해시값과 비교한다. 두 값이 일치하면 해당 어셈블리가 서명된 이후 변경되지 않았으며, 명시된 공개 키에 해당하는 비밀 키로 서명되었음을 신뢰할 수 있다.

5. 어셈블리와 CLI 보안

CLI의 코드 접근 보안은 어셈블리와 증거를 기반으로 작동한다. 증거는 주로 어셈블리의 출처 정보를 나타내는데, 예를 들어 어셈블리가 인터넷이나 인트라넷에서 다운로드되었는지, 아니면 사용자 컴퓨터에 직접 설치되었는지 등을 알려준다. 다른 컴퓨터에서 다운로드된 어셈블리는 샌드박스 위치인 GAC 내에 저장되므로 로컬 설치로 간주되지 않는다.

파일 시스템 권한은 어셈블리 전체에 적용되며, 개발자는 어셈블리가 실행되기 위해 필요한 최소한의 권한을 CLI 메타데이터 내 사용자 지정 특성을 통해 명시할 수 있다. CLR은 어셈블리를 로드할 때 이 증거 정보를 바탕으로 해당 어셈블리에 부여할 권한 집합을 생성한다. 이후 CLR은 이 생성된 권한 집합이 어셈블리에서 요구하는 최소 필수 권한을 모두 포함하고 있는지 검사한다.

CLI 코드는 실행 중 특정 작업을 수행하기 전에 '코드 접근 보안 요구'를 할 수 있다. 이는 현재 실행 호출 스택에 있는 모든 메서드의 모든 어셈블리가 특정 권한을 가지고 있는지 확인하는 과정이다. 만약 스택 내의 어느 한 어셈블리라도 필요한 권한이 없다면, 보안 관련 예외가 발생하여 작업이 중단된다.

또는 CLI 코드는 '연결된 요구'를 수행하여 호출 스택에서 권한을 얻을 수도 있다. 이 경우 CLR은 호출 스택 전체를 검사하는 대신, 스택의 가장 위에 있는(가장 최근에 호출된) 단일 메서드만 확인하여 필요한 권한이 있는지 검사한다. 이는 해당 메서드가 필요한 권한을 가지고 있다면, 그 아래 스택의 다른 메서드들도 암묵적으로 권한을 가진 것으로 간주하는 방식이다.

스푸핑 공격과 같이 악의적인 사용자가 어셈블리를 위장하려는 시도를 막기 위해, 어셈블리는 디지털 서명^[1] 기술을 사용한다. 개발자는 자신만이 아는 개인 키로 어셈블리에 서명한다. 이 개인 키는 비밀로 유지되므로 다른 사람이 어셈블리를 임의로 수정하고 다시 서명하는 것이 불가능하다. 서명 과정에는 어셈블리의 중요 데이터에 대한 해시 값을 계산하고, 이를 개인 키로 암호화하는 작업이 포함된다. 이 암호화된 해시 값과 공개 키는 어셈블리 내에 함께 저장된다. CLR이 강력한 이름을 가진 어셈블리를 로드할 때, 어셈블리 데이터로부터 다시 해시 값을 계산하고, 저장된 암호화된 해시를 공개 키로 복호화한 값과 비교한다. 두 값이 일치하면 해당 어셈블리가 변조되지 않았고, 명시된 게시자가 서명한 것임을 신뢰할 수 있게 되어 스푸핑 공격을 효과적으로 방지한다.

6. 위성 어셈블리

일반적으로 어셈블리는 특정 문화권에 구애받지 않는 중립적인 리소스를 포함해야 한다. 만약 어셈블리를 특정 지역이나 언어에 맞게 현지화하고 싶다면(예를 들어, 로케일에 따라 다른 문자열을 사용하고 싶을 때), 위성 어셈블리(satellite|새틀라이트^영어)를 사용해야 한다. 위성 어셈블리는 이름에서 알 수 있듯이, 주 어셈블리(main assembly)라고 불리는 핵심 어셈블리에 연결되는, 리소스만을 담고 있는 특별한 종류의 어셈블리이다. 위성 어셈블리에는 실행 코드가 포함되어서는 안 되며, CLI의 어셈블리 로더(Fusion)에 의해 직접 로드되지 않는다.

각 위성 어셈블리는 주 어셈블리의 파일 이름 끝에 ".resources"를 덧붙인 형태의 이름을 갖는다. 예를 들어, 주 어셈블리가 `lib.dll`이라면, 그에 연결된 위성 어셈블리의 파일 이름은 `lib.resources.dll`이 된다. 위성 어셈블리는 특정 문화권(예: 영국 영어(en-GB)) 정보를 담고 있지만, 윈도우의 파일 시스템(FAT32, NTFS)은 파일 이름만으로는 동일한 이름의 파일을 구분할 수 없다. 따라서 서로 다른 문화권의 위성 어셈블리 파일 이름이 중복되는 문제를 피하기 위해, 각 위성 어셈블리는 해당 문화권의 이름을 딴 하위 폴더 안에 저장해야 한다. 예를 들어, 영국 영어(en-GB) 문화권의 리소스를 담은 위성 어셈블리는 CLI 상에서는 `"lib.resources Version=0.0.0.0 Culture=en-GB PublicKeyToken=null"`과 같은 고유한 이름을 가지며, 실제 파일인 `lib.resources.dll`은 애플리케이션 폴더 아래의 `en-GB`라는 하위 폴더에 저장된다.

위성 어셈블리는 `System.Resources.ResourceManager` 클래스에 의해 로드된다. 개발자가 리소스의 이름과 주 어셈블리(중립 리소스를 포함하는)에 대한 정보를 제공하면, `System.Resources.ResourceManager` 클래스는 현재 시스템의 로케일(지역 및 언어 설정)을 확인한다. 이 로케일 정보와 주 어셈블리 이름을 조합하여 필요한 위성 어셈블리의 이름과 그것이 저장된 하위 폴더의 경로를 알아낸다. 그 후, 해당 경로에서 위성 어셈블리를 로드하여 현지화된 리소스를 가져올 수 있게 된다.

7. 어셈블리 참조

C# 컴파일러의 `/reference` 플래그를 사용하여 실행 가능한 코드 라이브러리를 참조할 수 있다.

8. 어셈블리 지연 서명

공유 어셈블리는 여러 애플리케이션에서 함께 사용될 수 있으므로, 각 어셈블리를 고유하게 구별할 방법이 필요하다. 이를 위해 강력한 이름(Strong Name)을 사용한다. 강력한 이름은 공개 키 토큰, 문화(Culture), 버전(Version), 그리고 PE 파일 이름으로 이루어진다.

개발 과정에서 공유 어셈블리를 사용해야 할 경우, 완전한 서명 절차 대신 지연 서명(Delay Signing) 방식을 활용할 수 있다. 지연 서명은 개발 단계에서는 공개 키만 생성하여 어셈블리에 포함시키는 방식이며, 이때 개인 키는 생성하지 않는다. 실제 개인 키를 이용한 최종 서명은 어셈블리를 사용자에게 배포하는 시점에 이루어진다. 이 방식을 통해 개발 중에는 서명 과정을 간소화하고, 배포 시점에는 강력한 이름으로 보안을 확보할 수 있다.

9. 어셈블리의 언어

어셈블리는 중간 언어인 CIL(Common Intermediate Language) 코드로 구성된다. .NET 프레임워크는 내부적으로 이 CIL(바이트코드)을 실행 시점에 각 플랫폼에 맞는 네이티브 어셈블리 코드로 변환한다.

Windows 환경의 .NET 프레임워크 구현에서 어셈블리는 PE 파일 형식을 따른다. 어셈블리에는 두 가지 종류가 있다:

• '''프로세스 어셈블리''': 실행 가능한 파일(EXE)
• '''라이브러리 어셈블리''': 동적 연결 라이브러리(DLL)

9. 1. CIL 코드 예제

10. Fusion

윈도우 파일 시스템은 어셈블리의 버전이나 문화 정보를 인식할 수 없어, 동일한 이름에 버전만 다른 어셈블리를 하나의 폴더에 저장할 수 없다.

퓨전(Fusion)은 이러한 파일 시스템의 한계를 극복하고 버전이나 문화 같은 정보를 파일 시스템상의 이름으로 사용할 수 있도록 하는 기술이다.

퓨전은 어셈블리를 찾을 때 정해진 순서에 따라 검색을 수행한다.

# 어셈블리가 강력한 이름을 가지고 있다면 먼저 전역 어셈블리 캐시를 검색한다.

# 다음으로 애플리케이션 설정 파일의 리다이렉트 정보를 확인한다. 어셈블리가 강력한 이름이라면 다른 버전을 로드하도록 지정하거나, 로컬 파일 시스템 또는 웹 서버상의 어셈블리를 절대 경로로 지정할 수 있다. 어셈블리가 강력한 이름이 아니라면 애플리케이션 폴더 아래의 하위 폴더를 검색 경로로 지정할 수 있다.

# 다음으로 애플리케이션 폴더 내에서 .exe나 .dll 확장자를 가진 어셈블리를 검색한다.

# 마지막으로 어셈블리의 짧은 이름과 같은 이름을 가진 하위 폴더 내에 있는 .exe 및 .dll 파일을 검색한다.

만약 이 과정에서도 어셈블리를 찾지 못하면, 퓨전은 예외를 발생시키고 어셈블리 이름이나 검색 경로 등의 정보를 저장한다. 이 정보는 퓨전 로그 뷰어(fuslogvw)를 통해 확인할 수 있다.

참조

_[1] 웹사이트 Giving a .NET Assembly a Strong Name https://web.archive.[...] 2007-03-29
_[2] 웹사이트 .NET Assembly Versioning Lifecycle http://philippetruch[...] 2008-08-12
_[3] 웹사이트 DLR Namespace Change Fire Drill https://web.archive.[...] 2008-09-17
_[4] 웹사이트 コンポーネントのバージョン管理 https://msdn.microso[...]
_[5] 웹인용 .NET Assembly Versioning Lifecycle http://philippetruch[...] 2008-08-12
_[6] 웹인용 DLR Namespace Change Fire Drill http://devhawk.net/2[...] 2008-09-17