멀티레벨 보안

Multilevel security

MLS(Multilevel Security or Multiple Level of Security)는 컴퓨터 시스템의 응용 프로그램으로, 호환되지 않는 분류(즉, 다른 보안 수준)의 정보를 처리하고, 보안 클리어런스와 알아야 할 필요가 있는 사용자의 접근을 허용하며, 사용자가 작성자가 없는 정보에 액세스할 수 없도록 합니다.이제이션멀티 레벨 시큐러티의 사용에는, 2개의 콘텍스트가 있습니다.하나는 전복으로부터 스스로를 보호하는 데 적합하고 정보 도메인을 분리하는 강력한 메커니즘, 즉 신뢰할 수 있는 시스템을 지칭하는 것입니다.또 다른 맥락은 컴퓨터가 전복으로부터 스스로를 보호할 수 있을 만큼 강하고 정보 도메인을 분리하기 위한 적절한 메커니즘, 즉 우리가 신뢰해야 하는 시스템을 필요로 하는 컴퓨터의 응용을 언급하는 것입니다.신뢰할 수 있는 시스템이 반드시 신뢰할 수 있는 것은 아니기 때문에 이 구별이 중요합니다.

신뢰할 수 있는 운영 체제

MLS 운영 환경에서는 많은 경우 MLS 운영체제시스템(OS)을 기반으로 구축된 신뢰성이 높은 정보처리 시스템이 필요하지만 반드시 필요한 것은 아닙니다.대부분의 MLS 기능은 하드웨어 보안 준거 채널에 의해 링크된 여러 개의 독립된 컴퓨터가 필요하지만 신뢰할 수 없는 컴퓨터에서 전적으로 지원됩니다(NCSC-TG-005 섹션 B.6.2 참조).하드웨어에 의해 강제되는 MLS의 예로는 비대칭 [1]분리가 있습니다.1대의 컴퓨터가 MLS 모드로 사용되고 있는 경우는, 그 컴퓨터는 신뢰할 수 있는 operating system(OS)을 사용할 필요가 있습니다.MLS 환경의 모든 정보는 OS에 의해 물리적으로 액세스 가능하기 때문에 정보에 대한 접근을 엄격하게 제어하기 위해서는 강력한 논리 제어가 필요합니다.일반적으로 여기에는 Bell-LaPadula 모델과 같은 보안 라벨을 사용하는 필수 접근 제어가 포함됩니다.

신뢰할 수 있는 운영 체제를 도입하는 고객은 일반적으로 제품이 공식적인 컴퓨터 보안 평가를 완료해야 합니다.평가는 시스템이 처리할 수 있는 최저 및 최고 수준의 분류 수준인 광범위한 보안 범위에 대해 더 엄격합니다.Trusted Computer System Evaluation Criteria(TCSEC; 신뢰할 수 있는 컴퓨터 시스템 평가 기준)는 컴퓨터 시스템에서 MLS를 평가하기 위해 개발된 첫 번째 평가 기준입니다.이 기준에서는 보안요건과 MLS 보안범위의 폭 사이에 명확한 균일한[2] 매핑이 존재했습니다.지금까지 보안 범위가 Unclassified ~ Top Secret인 MLS 처리가 가능한 실장은 거의 없었습니다.그 중에는 허니웰의 SCOMP, USAF SACDIN, NSA의 Blacker, 보잉의 MLS LAN 등이 있으며 모두 TCSEC, 1980년대 빈티지 및 Intel 80386 기반의 제품이다.현재 MLS 제품은 공통 기준에 따라 평가되고 있습니다.2008년 말, 첫 번째 운영체제(이하)는 고도의 보안 위협 환경에서 다단계 보안을 필요로 하는 미국 정부 프로그램의 후원으로 평가된 높은 보증수준(EAL) - EAL 6+ / High Robustness)으로 인증되었습니다.이 보증수준은 구 Orange Book A1(공식적인 방법 등)과 많은 유사점을 가지고 있지만 기능요건은 Bell-La Padula와 같은 상위 수준 정책보다는 근본적인 격리 및 정보 흐름 정책에 초점을 맞추고 있습니다.Common Criteria는 TCSEC의 Assurance(EAL; 보증)와 기능(보호 프로파일)의 페어링을 분리하였으므로 Common Criteria가 Rainbow Series를 대체함에 따라 보안 요건과 MLS 보안 범위 기능 간의 명확한 균일한 매핑이 상실되었습니다.

MLS를 지원하는 일부 기능을 갖춘 무료로 이용 가능한 운영 체제에는 보안 강화 Linux 기능이 활성화된 Linux 및 FreeBSD가 [3]있습니다.보안 평가는 다음과 같은 3가지 이유로 이러한 무료 MLS 구현에 문제가 있다고 생각되었습니다.

  1. MLS 신뢰에 필요한 정밀도로 커널 자기 보호 전략을 구현하는 것은 항상 매우 어렵습니다.이러한 예는 MLS 보호 프로파일에 대해 설계 또는 인증되지 않았기 때문에 MLS 지원에 필요한 자기 보호를 제공하지 않을 수 있습니다.
  2. EAL 레벨 이외에 Common Criteria에는 MLS 모드에서 동작하기 위해 필요한 견고성을 규정하는 적절한 높은 보증 보호 프로파일의 인벤토리가 없습니다.
  3. (1)과 (2)를 충족하더라도 평가 프로세스는 매우 비용이 많이 들고 평가된 소프트웨어의 구성 관리에 특별한 제약을 가합니다.

이러한 전제에도 불구하고 Red Hat Enterprise Linux 5는 2007년 [4]6월에 EAL4+에서 LSPP, RBACPP 및 CAPP에 대해 인증을 받았습니다.Security-Enhanced Linux를 사용하여 MLS를 구현하고 Security-Enhanced Linux에서 TOE 보안 속성을 적용하는 첫 번째 공통 기준 인증입니다.

벤더의 인증 전략은 일반인에게 오해를 불러일으킬 수 있습니다.일반적인 전략은 EAL 3 보호 프로파일(CAPP 등)[5]을 EAL 4 또는 EAL 5와 같은 높은 수준으로 인증하는 것과 같은 과도한 인증으로 EAL 수준을 강조하는 일반인의 과도한 강조를 악용한다.다른 하나는 MLS 지원 기능(Role-Based Access Control Protection Profile(RBACPP; 롤베이스 액세스컨트롤 보호 프로파일)이나 Labeled Security Protection Profile(LSPP; 라벨이 부착된 보안 보호 프로파일) 등)을 MLS 지원 프로파일로 평가되지 않는 커널에 추가 및 인증하는 것입니다.이러한 유형의 기능은 커널에서 실행되는 서비스이며 커널에 의존하여 손상 및 하위 버전으로부터 보호합니다.커널이 MLS 대응 보호 프로파일에 대해 평가되지 않은 경우 시연의 외관에 관계없이 MLS 기능을 신뢰할 수 없습니다.특히 주의할 점은 CAPP는 MLS에 중요한 자기 보호 기능을 제외하기 때문에 MLS 대응 프로파일이 아니라는 점입니다.

General Dynamics는 신뢰할 수 있는 MLS 운영체제인 PitBull을 제공합니다.PitBull은 현재 Red Hat Enterprise Linux의 향상된 버전으로만 제공되지만 Sun Microsystems Solaris, IBM AIX 및 SVR4 Unix용 이전 버전이 있었습니다.PitBull은 Bell LaPadula 보안 메커니즘, Biba 무결성 메커니즘, 슈퍼 사용자 권한 대체 및 기타 많은 기능을 제공합니다.PitBull은 2009년부터 General Dynamics의 Trusted Network Environment(TNE) 제품에 대한 보안 기반을 보유하고 있습니다.TNE는 다양한 분류 수준을 운영하는 국방부 및 정보기관 커뮤니티의 사용자에게 멀티레벨 정보 공유 및 접근을 가능하게 합니다.또한 다단계 연합 공유 환경인 전장 정보 수집 및 이용 시스템 확장[6](BIS-X)의 기반이기도 합니다.

현재 Oracle Corporation이 된 Sun Microsystems는 상용 OS Solaris 및 OpenSolaris의 통합 기능으로 Solaris Trusted Extensions를 제공합니다.Trusted Extensions는 Controlled Access Protection Profile(CAPP; 제어 액세스 보호 프로파일) 및 Role-Based Access Control(RBAC; 롤베이스 액세스컨트롤) 보호 프로파일과 더불어 라벨이 부착된 보안 보호 프로파일(LSP)[7]에 대해서도 EAL4에서 인증되었습니다.보안 대상에는 데스크톱 및 네트워크 기능이 모두 포함됩니다.LSPP는 사용자에게 커널 및 X Window System(X11 서버)에 의해 적용되는 라벨링 정책을 덮어쓸 권한이 없음을 요구합니다.평가에는 비밀 채널 분석이 포함되지 않습니다.이러한 인증은 CAPP에 의존하기 때문에 Common Criteria 인증에서는 이 제품이 MLS에 대해 신뢰할 수 있음을 시사하지 않습니다.

BAE Systems는 벤더가 주장하는 '고보증'으로 MLS를 지원하는 상용 시스템인 XTS-400을 제공합니다.이전 제품(XTS-300 포함)은 MLS를 지원하는 TCSEC B3 수준에서 평가되었습니다.XTS-400은 EAL5+의 공통 기준에 따라 CAPP 및 LSPP 보호 프로파일에 대해 평가되었습니다.CAPP와 LSPP는 둘 다 본질적으로 MLS를 지원하지 않는EAL3 보호 프로파일입니다만, 이 제품의 Common Criteria 평가의 시큐러티[8] 타겟에는, MLS 기능을 제공하는 풍부한 시큐러티 기능이 포함되어 있습니다.

문제 영역

Sanitization은 MLS 시스템의 문제 영역입니다.Bell-LaPadula 모델에서 정의된 것과 같이 MLS 제한을 구현하는 시스템에서는 공유가 명백히 보안 제한을 위반하지 않는 경우에만 허용됩니다.클리어런스가 낮은 사용자는 클리어런스가 높은 사용자와 작업을 쉽게 공유할 수 있지만 그 반대는 아닙니다.Top Secret 사용자가 Top Secret 파일을 편집하여 모든 Top Secret 정보를 삭제한 후 Secret 이하의 클리어로 사용자에게 전달할 수 있는 효율적이고 신뢰할 수 있는 메커니즘은 없습니다.실제로 MLS 시스템은 신뢰할 수 있는 사용자가 MLS 메커니즘을 우회하여 파일의 보안 분류를 변경할 수 있는 특권 기능을 통해 이 문제를 회피합니다.그러나 이 기술은 신뢰할 수 없습니다.

MLS 시스템에 다른 문제가 되는 것은 비밀 채널입니다.MLS 시스템이 비밀을 완벽하게 유지하려면 Top Secret 프로세스가 어떤 종류의 신호든 Secret 이하의 프로세스에 전송할 수 있는 방법이 없어야 합니다.여기에는 사용 가능한 메모리 또는 디스크 공간 변경 또는 프로세스 타이밍 변경과 같은 부작용이 포함됩니다.프로세스가 이러한 부작용을 이용하여 데이터를 전송하는 경우, 이는 비밀 채널을 이용하는 것입니다.실용적인 컴퓨팅 시스템에서 모든 비밀 채널을 닫는 것은 매우 어렵고, 실제로 불가능할 수도 있습니다.모든 비밀 채널을 식별하는 과정 자체가 어려운 과정입니다.시판되고 있는 대부분의 MLS 시스템은 보안성이 높은 어플리케이션에서는 사용하지 않지만 모든 비밀 채널을 닫으려고 하지 않습니다.

바이패스는 시스템하이 오브젝트를 MLS를 신뢰하는 것처럼 취급하는 수단으로 도입되면 문제가 됩니다.일반적인 예는 기밀이 아닌 대상으로 전송되는 비밀 시스템 높음 객체에서 데이터를 추출하는 것으로, 데이터의 일부 속성을 '진짜' 기밀이 아닌(예: '엄격한' 형식) 신뢰할 수 있는 증거로 인용한다.신뢰할 수 있는 증거를 보존하기 위해 시스템 하이 시스템을 신뢰할 수 없으며, 그 결과 데이터를 안전하게 중재하는 논리적 방법 없이 공개 데이터 경로가 열립니다.바이패스는 이용하기 어려운 좁은 대역폭의 은닉채널과는 달리 시스템에서 부정 이용하기 쉬운 대규모 공공누설이 발생할 수 있기 때문에 위험할 수 있습니다.신뢰할 수 있는 운영 환경을 사용하여 보안 도메인을 지속적으로 분리하여 원래 위치로 되돌리는 데 실패하여 바이패스가 발생하는 경우가 많습니다.그 송신원이 시스템 경계 밖에 있는 경우는, 그 송신원에 대한 신뢰된 분리를 검증할 수 없는 경우가 있습니다.이 경우 흐름이 정말로 필수적인 경우 바이패스의 위험은 피할 수 없습니다.

피할 수 없는 바이패스의 일반적인 예로는 신뢰할 수 없는 소스로부터의 비밀 IP 패킷을 받아들여 헤더가 아닌 비밀 사용자 데이터를 암호화하고 결과를 신뢰할 수 없는 네트워크에 저장해야 하는 대상 시스템이 있습니다.근원은 주체 시스템의 영향권 밖에 있다.송신원은 신뢰할 수 없지만(예를 들어 시스템하이), MLS 데이터 컨스트럭트인 미분류 헤더와 비밀 플레인텍스트 유저 데이터를 가지는 패킷을 제공하기 때문에, MLS 와 같이 신뢰되고 있습니다.송신원은 신뢰할 수 없기 때문에, 파손되어 분류되지 않은 패킷헤더에 비밀이 배치될 가능성이 있습니다.파손된 패킷헤더는 난센스일 수 있지만 대상 시스템이 그것을 합리적인 신뢰성으로 판별하는 것은 불가능합니다.패킷 사용자 데이터는 암호화로 보호되지만 패킷헤더에는 판독 가능한 비밀이 포함될 수 있습니다.파손된 패킷이 서브젝트시스템에 의해 신뢰할 수 없는 네트워크에 전달되면 라우팅이 불가능할 수 있지만 네트워크 내의 일부 공동 파손된 프로세스가 패킷을 포착하여 확인 응답을 할 수 있으며 서브젝트시스템이 리크를 검출하지 못할 수 있습니다.이는 검출하기 어려운 대규모 공공 누출일 수 있습니다.분류되지 않은 헤더를 가진 분류된 패킷을 MLS 구조가 아닌 시스템상 높은 구조로 보는 것은 매우 일반적이지만 심각한 위협이 됩니다.

대부분의 바이패스는 피할 수 있습니다.회피 가능한 바이패스는 시스템 설계자가 보안을 올바르게 고려하기 전에 시스템을 설계한 후 추가 기능으로 보안을 적용하려고 할 때 자주 발생합니다.이 상황에서는 바이패스가 시스템을 작동시키는 유일한 (간단한) 방법인 것 같습니다.바이패스된 데이터에 비밀이 포함되어 있지 않음을 확인하기 위해 바이패스된 데이터의 내용을 검사하는 의사 보안 스킴이 제안(및 승인됨!)되고 있습니다.이는 원본 데이터의 특성을 보존하기 위해 원본이 신뢰되지 않는다는 가정에 반하는 형식과 같은 데이터에 대한 신뢰 없이는 불가능합니다.보안 바이패스는 바이패스를 투명하게 구현하는 이른바 HAG(High Assurance Guard)와 마찬가지로 신화입니다.이러한 리스크는 오랫동안 인정되어 왔습니다.기존 솔루션은 궁극적으로 기술적인 것이 아니라 절차적인 것입니다.바이패스의 악용에 의해 우리 시스템에서 얼마나 많은 기밀 정보가 취득되는지를 확실히 알 수 있는 방법은 없습니다.

MLS 같은 건 없어요.

COMPUSEC 전문가가 감소하여 MLS 용어가 오버로드되었습니다.일반인들은 안전한 컴퓨팅 시스템을 설계하고 MLS가 존재하지 않는다는 결론을 내리고 있습니다.이러한 2가지 용도는 처리 환경으로서의 MLS와 기능으로서의 MLS입니다.MLS가 존재하지 않는 것은 MLS 환경 또는 모드에서 동작하도록 인증된 제품이 없기 때문에 기능으로서의 MLS가 존재하지 않는다는 믿음에 기초하고 있습니다.하나는 다른 하나를 의미하지 않는다.많은 시스템은 보안 수준이 동일하지 않은 데이터를 포함하는 환경에서 작동하므로 Computer Security Intermediate Value Orginary(CS-IVT;[10] 컴퓨터 보안 중간값 정리)에 의해 MLS가 됩니다.이 혼란의 결과는 더 심각하다.NSA 인증 MLS 운영체제시스템, 데이터베이스 및 네트워크는 1970년대부터 운용모드로 존재해 왔으며 MLS 제품은 계속 구축, 마케팅 및 도입되고 있습니다.

일반인들은 시스템이 MLS 환경에서 동작하는 것을 인정하는 것(MLS의 환경 중심적 의미)은 MLS 솔루션(MLS의 기능 중심적 의미)이 없는 문제의 인식 코너로 되돌아가는 것이라고 종종 결론짓습니다.MLS는 믿을 수 없을 정도로 복잡하며 단순한 해결책이 명확하지 않다고 해서 그것이 존재하지 않는다는 결론이 정당화되지는 않는다.이로 인해 COMPUSEC에 대한 심각한 무지로 이어질 수 있습니다.이러한 MLS 거부 스킴은, 「MLS에 대해서는 말할 수 없다」, 「MLS와 같은 것은 없다」라고 하는 속삭임으로 나타나 있습니다.이러한 MLS 거부 스킴은, 대처가 불가능할 정도로 급속히 변화합니다.대신 MLS 환경과 MLS 대응의 구별을 명확히 하는 것이 중요합니다.

  • 보안 환경 또는 보안 모드로서의 MLS:사용자의 보안 클리어 수가 다른 커뮤니티에서는 MLS를 데이터 공유 기능으로 인식할 수 있습니다.사용자는 클리어에 의해 정보를 수신할 수 있는 수신자와 정보를 공유할 수 있습니다.시스템이 MLS 모드로 동작하고 있는 것은, MLS 시스템에 포함되는 데이터보다 낮은 시큐러티 레벨로 클리어 된 행선지에의 접속이 있는 경우(또는 접속할 가능성이 있는 경우)입니다.이것은 CS-IVT로 정식화되어 있습니다.시스템의 보안 모드 판정은 전적으로 시스템의 보안 환경, 포함된 데이터의 분류, 시스템 또는 그 출력 또는 신호에 직접 또는 간접적으로 접근할 수 있는 사용자의 클리어런스, 시스템의 다른 시스템과의 접속 및 포트에 따라 달라집니다.보안 모드는 기능에 의존하지 않지만 신뢰할 수 없는 모드로 시스템을 운용해서는 안 됩니다.
  • 기능으로서의 MLS:MLS 데이터 공유를 허용하는 제품 또는 시스템 개발자는 Bell-LaPadula 모델을 적용하는 메커니즘과 같이 데이터 공유 제한 또는 보안 정책을 적용하는 기능 측면에서 MLS 데이터 공유를 느슨하게 인식하는 경향이 있습니다.시스템이 보안 정책을 확실하게 구현하고 있는 것을 확인할 수 있는 경우, 시스템은 MLS 대응하고 있습니다.

보안 환경 또는 모드에 적용되는 MLS라는 용어의 최초 사용.이 혼란에 대한 해결책 중 하나는 MLS의 원래 정의를 유지하고 해당 컨텍스트를 사용할 때 MLS 대응에 대해 특정하는 것입니다.

MILS 아키텍처

MILS(Multiple Independent Levels of Security)는 MLS의 도메인 분리 컴포넌트에 대응하는 아키텍처입니다.UCDMO(크로스 도메인 및 멀티레벨 시스템용 미국 정부 주도)가 DoD 및 Intelligence Community 인정 시스템의 베이스라인에서 카테고리로서 크로스 도메인 액세스라는 용어를 작성한 것에 주의해 주십시오.이 카테고리는 다음과 같습니다.n은 본질적으로 MILS와 유사하다.

Biba 모델(정합성을 위한) 및 Bell-LaPadula 모델(비밀성을 위한)과 같은 보안 모델은 격리된 것으로 간주되는 특정 보안 도메인 간의 단방향 흐름을 가능하게 한다.MILS는 상기 모델에 의해 주소 지정된 도메인 간의 제어된 상호작용에 대처하지 않고 MLS의 기초가 되는 분리에 대처합니다.상기의 신뢰할 수 있는 보안 준거 채널은 MILS 도메인을 링크하여 더 많은 MLS 기능을 지원할 수 있습니다.

MILS 접근방식은 오래된 용어인 MSL(복수 단일 레벨)로 특징지어지는 전략을 추구하며, 각 레벨의 정보를 자체 단일 레벨 환경(시스템 하이) 내에서 격리합니다.

MILS가 제공하는 엄격한 프로세스 통신 및 격리는 MLS보다 초고신뢰 소프트웨어 애플리케이션에 더 유용할 수 있습니다.MILS는 특히 보안 수준의 개념에 의해 구현되는 계층 구조를 다루지 않습니다.이를 위해서는 도메인 간에 특정 Import/export 어플리케이션을 추가해야 합니다.이러한 어플리케이션은 각각 적절하게 인증되어야 합니다.따라서 MILS는 Multiple Independent Domains of Security(MILS 상의 MLS 에뮬레이션은 MLS 어플리케이션에도 동일한 인정 어플리케이션세트를 필요로 합니다).Bell-La Padula의 계층적 관계와 일치하는 수준 간의 즉각적인 상호작용을 거부함으로써 MILS는 처음에는 구현이 간단하지만 실제 MLS 애플리케이션에서 기대하는 풍부함과 유연성을 달성하기 위해 사소한 추가 Import/export 애플리케이션이 필요합니다.

MILS/MLS 비교에서는 단순한 내보내기 어플리케이션 세트를 인증하는 것이 복잡한 MLS 커널을 인증하는 것보다 더 달성 가능한지 여부를 고려해야 합니다.이 질문은 이해관계자가 요구하는 수입/수출 상호작용의 정도에 따라 부분적으로 달라진다.MILS에 유리한 것은 모든 수출 애플리케이션이 최대한의 보증을 필요로 하는 것은 아니라는 점이다.

MSL 시스템

이러한 문제를 해결하는 또 다른 방법은 다중 단일 레벨로 알려져 있습니다.각 보안 수준은 별도의 신뢰할 수 없는 도메인 내에서 격리됩니다.도메인간에 통신 매체가 없는 것은, 어떠한 상호 작용도 할 수 없다는 것을 보증합니다.이 분리를 위한 메커니즘은 일반적으로 개별 컴퓨터에서의 물리적 분리에 있습니다.이것은, Microsoft Windows 와 같이 MLS 를 서포트할 가능성이 없는 애플리케이션이나 operating system을 서포트하기 위해서 자주 사용됩니다.

적용들

신뢰할 수 있는 운영체제시스템 등의 인프라스트럭처는 MLS 시스템의 중요한 컴포넌트입니다만, CNSSI 4009에 의한 MLS의 정의에 준거하기 위해서(이 문서의 선두에 기재되어 있습니다) 시스템은, 유저가 복수의 분류로 컨텐츠에 액세스 해 처리할 수 있는 유저 인터페이스를 제공할 필요가 있습니다.캐티온 레벨을 설정할 수 있습니다.UCDMO는 2009년 NSA Information Assurance Symposium에서 MLS에 특화된 트랙을 운영하여 인증(생산 중)된 MLS 시스템 및 긴급 MLS 시스템을 강조하였습니다.SELinux [11]에서의 MLS 의 사용에 주의해 주세요.

MLS 시스템으로 분류되는 데이터베이스가 몇 개 있습니다.Oracle에는 Oracle 데이터베이스의 각 테이블에 '라벨' 열을 추가하여 필수 액세스 제어를 구현하는 Oracle Label Security(OLS)라는 제품이 있습니다.OLS는 JWICS 및 SIPRNet 네트워크에 걸친 "모든 소스" 인텔리전스 데이터베이스의 기반으로서 미군 INSCOM에 배치되어 있습니다.Postgre의 라벨이 붙은 버전을 만드는 프로젝트가 있습니다.SQL 및 Trusted Rubix와 같은 오래된 라벨이 붙은 데이터베이스 구현도 있습니다.이러한 MLS 데이터베이스 시스템은 여러 라벨에 걸친 콘텐츠에 대해 통합된 백엔드 시스템을 제공하지만 사용자가 필수 접근컨트롤을 적용하면서 하나의 시스템에서 여러 보안 수준에서 콘텐츠를 처리해야 하는 문제를 해결하지는 않습니다.

MLS 최종 사용자 애플리케이션도 몇 가지 있습니다.현재 UCDMO 베이스라인에 있는 다른 MLS 기능은 Wayback Machine에서는 MLChat Archived 2013-03-17이라고 불리며, XTS-400 운영체제 상에서 실행되는 채팅서버입니다.이것은 미국 해군 연구소가 작성한 것입니다.다른 도메인의 사용자로부터의 컨텐츠가 MLChat 서버를 통과하기 때문에 기밀 콘텐츠를 보호하기 위해 더티워드 스캔이 사용됩니다.이 스캔이 실제로 MLS 시스템인지 크로스 도메인 전송 데이터 가드의 형태인지에 대해서는 몇 가지 논란이 있었습니다.필수 접근 제어는 XTS-400과 애플리케이션 고유의 [12]메커니즘의 조합으로 유지됩니다.

Joint Cross Domain eXchange(JCDX)는 현재 UCDMO 기준선에 있는 MLS 기능의 또 다른[permanent dead link] 예입니다.JCDX는 국방부(DoD)와 국방정보국(DIA)이 인가한 MLS(Multilevel Security) Command, Control, Communication, Computers and Intelligence(C4I; 다단계 보안, 제어, 통신, 컴퓨터 및 정보) 시스템 중 유일하게 전역 및 전진 배치된 전술 지휘관에게 거의 실시간 정보 및 경고 지원을 제공합니다.JCDX 아키텍처는 고도의 보안 보호 레벨 4(PL4)의 보안 운영체제와 포괄적으로 통합되어 있으며, 데이터 라벨링을 활용하여 전 세계 해양 및 그 주변에 무력 활동 및 잠재적 테러 위협에 대한 거의 실시간 데이터 정보를 배포합니다.이 소프트웨어는 미국 및 제휴 파트너 국가에서 단일 플랫폼에서 최고 기밀/SCI에서 기밀 해제 수준까지 데이터를 제공할 수 있는 위치에 설치됩니다.

현재 UCDMO 기준선에 포함되지 않은 MLS 애플리케이션에는 BlueSpace의 여러 애플리케이션이 포함되어 있습니다.BlueSpace에는 MLS 이메일클라이언트, MLS 검색 어플리케이션, MLS C2 시스템 등 여러 개의 MLS 어플리케이션이 있습니다.BlueSpace는 미들웨어 전략을 활용하여 애플리케이션을 플랫폼 중립으로 전환하고 여러 Windows OS 인스턴스(가상화 또는 원격 터미널 세션)에 걸쳐 하나의 사용자 인터페이스를 조정합니다.미국 해군 연구소는 또한 SQLite3 기반의 다단계 데이터베이스와 Ruby on Rails 프레임워크를 통합하는 ML Web이라는 다단계 웹 애플리케이션 프레임워크를 구현했습니다.

미래.

오늘날 멀티레벨 보안 분야에서 가장 큰 변화는 MLS와 가상화의 융합일 것입니다.점점 더 많은 신뢰할 수 있는 운영 체제가 파일 및 프로세스에 대한 레이블 지정에서 벗어나 UNIX 컨테이너 또는 가상 시스템으로 이동하고 있습니다.예를 들어 Solaris 10 TX의 존, Green Hill의 Integrity 플랫폼, Citrix의 XenClient XT 등의 시스템의 패딩된 셀 하이퍼바이저 등이 있습니다.General Dynamics의 Trusted Virtualization Environment(TVE)에 실장된 NSA의 High Assurance Platform도 그 핵심으로 SELinux를 사용하여 여러 도메인에 걸친 MLS 애플리케이션을 지원할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Davidson, J.A. (1996-12-09). "Asymmetric isolation". Proceedings 12th Annual Computer Security Applications Conference. Computer Security Applications Conference. pp. 44–54. doi:10.1109/CSAC.1996.569668. ISBN 978-0-8186-7606-2. S2CID 21977652.
  2. ^ CSC-STD-004-85: 컴퓨터 보안 요건 - 특정 환경에서의 국방부 신뢰 컴퓨터 시스템 평가 기준 적용 지침(1985년 6월 25일)
  3. ^ FreeB의 다단계 보안 기밀성 정책SD
  4. ^ "Validated Product - Red Hat Enterprise Linux Version 5 running on IBM Hardware". National Information Assurance Partnership, Common Criteria Evaluation and Validation Scheme, United States. June 7, 2007. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  5. ^ Controlled Access Protection Profile(CAPP)
  6. ^ Corrin, Amber (2017-08-08). "How BICES-X facilitates global intelligence". C4ISRNET. Retrieved 2018-12-10.
  7. ^ "Solaris 10 Release 11/06 Trusted Extensions". Communications Security Establishment Canada. 2008-06-11. Archived from the original on 2011-06-17. Retrieved 2010-06-26. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  8. ^ "Security Target, Version 1.22 for XTS-400, Version 6.4.U4" (PDF). National Information Assurance Partnership, Common Criteria Evaluation and Validation Scheme, United States. 2008-06-01. Archived from the original (PDF) on 2011-07-23. Retrieved 2010-08-11. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  9. ^ David Elliott Bell: Bell – LaPadula 모델 회고 - 부록 2011-08-27 Wayback Machine에서 아카이브됨(2006년 12월 20일)
  10. ^ David Elliott Bell: Bell-LaPadula 모델을 돌아봅니다(2005년 12월 7일)
  11. ^ 예를 들어 다음과 같습니다.
  12. ^ http://www.sse.gr/NATO/EreunaKaiTexnologiaNATO/36.Coalition_C4ISR_architectures_and_information_exchange_capabilities/RTO-MP-IST-042/MP-IST-042-12.pdf[영구 데드링크]

추가 정보

외부 링크