정보 보안 기본 정보

InfoSec의 주요 목표는 무엇입니까?

컨텍스트 경계의 모든 변경 사항이 제대로 규제되도록 합니다.

예를 들어 UNIX 플랫폼의 모든 시스템 호출은 UNIX 사용자/그룹 프로세스+파일 시스템 보안 모델 측면에서 이러한 조건을 충족합니다. 시스템 호출에 의해 입력된 컨텍스트 스위치의 리터럴 정의에는 커널에서 API 사용 온전성 검사가 포함됩니다.’호출의 측면입니다.

SaaS 납품의 관점에서, 런타임 UNIX 시스템 호출에서 시작된 모든 데이터는 유지됨으로 처리되어야 합니다.애플리케이션에 대한 수신 지점에서 검증’액세스 가능한 프로세스 메모리입니다. 이러한 수신 지점은 해당 애플리케이션 데이터에 대해 infosec 컨텍스트 경계로 간주되어야 합니다. 적절한 규제 검증은 일반적으로 regex를 통해 문자열 패턴을 허용 목록으로 표시해야 합니다. tainted는 허용 목록 및 종속 데이터를 지우는 데이터를 다른 시스템 호출을 통해 애플리케이션의 프로세스 메모리에서 안전하게 아웃바운드로 전송할 수 있습니다. 해당 시스템 호출 송신 지점도 infosec 컨텍스트 경계입니다. “안전” 수신 관리 데이터의 허용 목록 패턴은 송신 지점에서 이러한 특정 API에 의해 통지됩니다. SSDLC에서 이러한 송신 지점은 해당 허용 목록과 마찬가지로 진화합니다.

UNIX 보안 모델만으로는 네트워크 클라이언트/서버 응용 프로그램 개발을 위한 조항을 만들지 않았습니다. 90s(Sun Microsystems)에서 네트워크 컴퓨팅의 상승을 앞둔 BSD 소켓 API는 UNIX가 태어난 후 10년 동안 발명되었습니다(OS 기반 다중 사용자 보안 모델이 탄생 시 완전히 형성됨). MIT Kerberos 올바른 방향으로 나아가는 단계였지만 SaaS 컨텍스트에서 원하는 만큼 남습니다.

일부 CPU 대신 커널 레벨 작업을 수행하도록 CPU를 안전하게 예약 “권한이 부여된 사용자/그룹/역할 컨텍스트” 기본 프로세스에 연결되지 않음’UNIX 사용자/그룹 컨텍스트는 항상 UNIX 모델 외부에 있습니다. 많은 infosec 이니셔티브는 이러한 규제 책임을 인식하지 못합니다.’너의 하나가 되게 하라!

경우에 따라’이 시점에서 명확하지 않다, 리눅스에서 SaaS 보안 (CAI) 사고를 승리 DevOps / SRE 팀은 자신에 익숙해야 상단‘초 문자열 인터페이스를 통해 초 키! 더 나은 마스터 문자열 독립형으로. (FYI: SSH/SSM 전달을 포함하여 K8s 컨테이너 또는 노드로 전달할 수 있는 github에 이러한 바이너리의 정적 컴파일이 있습니다. https://github.com/joesuf4/home/tree/wsl/bin).

이것이 Zero-Trust 이니셔티브와 실제 문제로 어떤 관련이 있습니까?

제로 트러스트 아키텍처 네트워크별 infosec 컨텍스트 경계가 없습니다.

실제로 VPN/방화벽 컨텍스트가 있을 수 있지만 이러한 세부 정보는 제로 트러스트 프레임워크 내에서 InfoSec와 관련이 없습니다. 즉, 이러한 네트워크 토폴로지 보안 이니셔티브는 제로 트러스트(Zero-Trust) 이니셔티브를 강화할 수 있지만, 기본 서버 호스트 보안 수준에서 애플리케이션 수준까지 제로 트러스트(Zero-Trust) 이니셔티브에 의존하지 않습니다.

예를 들어, MIT Kerberos 및 Active Directory는 Zero-Trust를 준수합니다.