test

Trusted Solaris 관리 개요

Trusted Solaris에서의 라우팅

Trusted Solaris 운영 환경에서 서로 다른 네트워크의 호스트 간의 경로는 각 전송 단계마다 보안이 유지되어야 합니다.

부트할 때 라우팅 정보 읽어들이기

Trusted Solaris 호스트는 부트할 때 데이터를 전송할 수 있도록 라우팅 정보를 읽어 들입니다. 관리자가 수동으로 유지하는 /etc/tsolgateways 파일이 있으면 이 파일의 게이트웨이가 호스트 기본값으로 사용됩니다. /etc/tsolgateways가 없으면 호스트는 관리자가 수동으로 유지하는 /etc/defaultrouter의 기본 경로를 사용합니다. 두 파일 중 어느 하나라도 있으면 호스트는 정적 라우팅을 사용합니다.

/etc/tsolgateways 파일과 /etc/defaultrouter 파일이 모두 없으면 호스트가 동적 라우팅을 사용해서 가능한 경우 in.rdisc(1M)(네트워크 라우터 검색 대몬)을, in.rdisc를 사용할 수 없으면 in.routed(1M)(네트워크 라우팅 대몬) 같은 특별 대몬을 실행해야 합니다. 호스트가 둘 이상의 네트워크에 연결되는 호스트인 게이트웨이로도 사용될 경우에는 in.rdisc와 in.routed가 모두 시작됩ㄹ니다.

부트할 때 호스트가 NIS+ 마스터와 통신할 수 있도록 tnrhdb와 tnrhtp 파일(/etc/security/tsol/boot 디렉토리에 상주하고 있는)을 커널로 읽어 들입니다. 이들 기본값은 트러스트 네트워크 대몬(tnd(1M))이 시작될 때 교체됩니다. 기본적으로 /etc/security/tsol/boot/tnrhdb는 0.0.0.0:tsol 항목을 포함하여 네트워크가 Trusted Solaris 네트워크임을 나타냅니다.

Trusted Solaris 환경에서의 라우팅 테이블

Trusted Solaris 환경에서 라우팅의 주 목적은 두 호스트 사이의 가장 안전한 단거리 경로를 찾는 것입니다. Trusted Solaris 라우팅 테이블은 확장 메트릭(emetrics라고 함)을 기본으로 합니다. emetric은 경로 설정 메트릭과 보안 측정을 위한 Security Routing Information(SRI)의 조합입니다. SRI는 다음과 같은 보안 속성을 통합할 수 있습니다.

이 정보는 동적 라우팅이 사용될 경우 Trusted Solaris 확장 Routing Information Protocol을 사용하는 라우팅 대몬 in.routed에 의해, 정적 라우팅이 사용될 경우 route 명령을 사용한 직접 입력 또는 /etc/tsolgateways나 /etc/defaultrouter 파일을 통해 전파됩니다. 특정 경로에 대한 emetric은 해당 경로가 고려하는 동안 인가 확인에 사용됩니다.

라우팅 테이블에 모든 경로에 emetric이 있는 것은 아닙니다. 경로가 emetric이 없는 경우 최초 홉 게이트웨이의 원격 호스트 템플리트가 인가 확인에 대신 사용됩니다.

인가 확인

보안에 관한 경로의 적합성을 결정하기 위해 Trusted Solaris는 원본 호스트, 대상 호스트 및 경로의 emetrics에서 인가 확인이라는 테스트를 실행합니다. 특정 경로에 대한 emetric이 손실된 경우 경로의 최초 홉 게이트웨이를 위한 보안 속성이 확인됩니다. 호스트의 보안 속성은 tnrhdb, tnrhtp 및 tnidb 파일의 정보에서 파생됩니다. 예를 들어 테스트는 데이터 패킷의 민감도 레이블이 경로의 각 호스트 범위 안에 있는지 확인합니다. 또 다른 예로, Trusted Solaris 호스트와 어떤 IP 옵션도 사용하지 않는 TSIX 호스트 사이에 전송된 데이터는 경로가 CIPSO, RIPSO 또는 MSIX 호스트를 사용하는 경우 허용되지 않습니다 .

원본 인가 확인

원본 호스트에서 관리되는 인가 확인은 다음과 같습니다.

게이트웨이 인가 확인

Trusted Solaris 게이트웨이 호스트에서 진행되는 인가 확인은 다음과 같습니다.

다음 홉이 unlabeled 호스트인 경우 패킷의 기본 레이블은 대상 호스트의 기본 레이블과 일치해야 합니다.

패킷에 CIPSO 옵션이 있는 경우 전달을 위한 아래 조건이 충족되어야 합니다.

패킷에 RIPSO 옵션이 있는 경우 전달을 위한 아래 조건이 충족되어야 합니다.

대상 인가 확인

Trusted Solaris 시스템이 데이터를 수신할 때 트러스트 네트워크 소프트웨어는 다음 항목을 확인합니다.

데이터가 위의 인가 확인을 통과하면 시스템은 필요한 보안 속성이 모두 있는지 확인합니다. 누락된 속성이 있는 경우 소프트웨어는 그 호스트에 할당된 네트워크 보안 템플리트 이름을 보기 위해 tnrhdb 데이터베이스에서 원본 호스트(각 IP 주소 또는 대상 표현에 의해)를 찾습니다. 그런 다음 소프트웨어는 tnrhtp 데이터베이스로부터 템플리트의 보안 속성을 검색합니다. 여전히 누락된 보안 속성이 있는 경우 소프트웨어는 tnidb 데이터베이스에서 네트워크 인터페이스를 찾아 기본 보안 속성을 검색합니다. 우선 순위에 따라 tnrhtp의 기본 속성은 tnidb의 속성보다 우선합니다.

라우팅 예제

다음 페이지의 그림은 Trusted Solaris 환경에서 경로를 설정하는 예제를 보여줍니다. 그림 5-8 (a)는 라우팅 다이어그램을 나타내고, 그림 5-8 (b)는 라우팅 테이블을 나타냅니다. Host 1과 Host 2 사이에는 다음과 같은 3가지의 잠재 경로가 있습니다.

그림 5-8 일반적인 Trusted Solaris 경로와 라우팅 테이블

Graphic

라우팅 명령 사용

라우팅 테이블의 내용을 표시하려면 -R 옵션이 있는 netstat 명령을 사용해야 합니다. 라우팅 테이블을 수동으로 변경하려면 add나 delete 옵션이 있는 route 명령을 사용합니다. 예를 들면 다음과 같습니다. 

% route add net 129.150.115.0 129.150.118.39 -m 
metric=2,min_sl=c,max_sl=ts,ripso_label="top_secret 
sci",ripso_error="genser;sci"add net 129.150.115.0: gateway 129.150.118.39

명령은 라우팅 테이블에 129.150.115.0 및 129.150.118.39에 있는 호스트와 distance metric 2, C에서 TS까지의 SL범위, RIPSO 레이블 = top_secret sci 및 RIPSO 오류 = genser;sci와 함께 루프를 추가합니다. 추가된 루프의 결과를 보려면 다음과 같이 입력합니다.

% netstat -Rn
...
129.150.115.0        129.150.118.39        UG       0      0  
        metric=2,min_sl=C,max_sl=TS,ripso_label=0x3d 0x20000000 (top_secret sci)
,ripso_error=0xa0000000 (genser;sci)
...

새 경로는 위의 내용과 같습니다. 다른 경로는 생략 부호(...)로 대체됩니다. 두 개의 새 emetric으로 경로를 추가하고 새 라우팅 테이블을 보여주는 두 번째 예제는 다음과 같습니다:

% route add net 129.150.114.0 129.150.118.39 -m 
metric=3,min_sl=admin_low,max_sl=s,doi=3 -m 
metric=4,min_sl=c,max_sl=admin_high,doi=4,ripso_label="top_secret 
sci",ripso_error="genser;sci"
add net 129.150.114.0: gateway 129.150.118.39
% netstat -Rn
...
129.150.115.0        129.150.118.39        UG       0      0  
        metric=2,min_sl=C,max_sl=TS,ripso_label=0x3d 0x20000000 (top_secret sci)
,ripso_error=0xa0000000 (genser;sci)
129.150.114.0        129.150.118.39        UG       0      0  
        metric=4,min_sl=C,max_sl=ADMIN_HIGH,doi=4,ripso_label=0x3d 0x20000000 (t
op_secret sci),ripso_error=0xa0000000 (genser;sci)
        metric=3,min_sl=ADMIN_LOW,max_sl=S,doi=3
...

비 Trusted Solaris 게이트웨이 클러스터를 통한 라우팅

비 Trusted Solaris 게이트웨이가 있는 클러스터를 통해 보안 데이터 경로를 라우팅할 수 있습니다. 이러한 프로시저를 터널링이라고 합니다. 이를 위해 클러스터는 Trusted Solaris 호스트와 게이트웨이 전용 또는 비 Trusted Solaris 호스트와 게이트웨이 전용의 연속 집합입니다. 에지 게이트웨이는 클러스터 하나를 반대 종류의 클러스터에 연결하는 게이트웨이(Trusted Solaris 또는 비 Trusted Solaris)입니다.

다음 그림은 터널링 예제를 보여줍니다. 음영 처리된 직사각형은 비 Trusted Solaris 게이트웨이를 나타내며 굵은 선의 루프는 클러스터를 나타냅니다. 클러스터 #1은 비 Trusted Solaris 클러스터이며 클러스터 #2는 Trusted Solaris 클러스터입니다.

그림 5-9 터널링 예제

Graphic

데이터를 호스트 #1에서 호스트 #2로 전송하려면 비 Trusted Solaris 클러스터인 클러스터 #1과 Trusted Solaris 클러스터인 클러스터 #2를 통과하는 경로가 필요합니다. 다음 두 조건에서만 허용됩니다.