시스템 아키텍처 설계 고급 기술 · 보안 아키텍처 설계 이론 및 실습

일련의 기사 디렉토리를 입력하려면 클릭하세요.

现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.

1. 정보보안 위협

1.1 정보시스템 보안 위협의 근원

위협은 물리적 환경, 통신 링크, 네트워크 시스템, 운영 체제, 애플리케이션 시스템 및 관리 시스템에서 발생할 수 있습니다.

1.2 네트워크 및 정보 보안 위험 범주

네트워크 및 정보 보안 위험 범주는 고의적인 파괴(수동적 공격, 능동적 공격), 재앙적인 공격, 시스템 오류, 직원의 무의식적인 행동으로 나눌 수 있습니다.
그림에 표시된 것처럼 네트워크 및 정보 보안의 위험 범주는 다음과 같습니다.

1.3 일반적인 보안 위협

일반적인 보안 위협은 주로 다음과 같습니다.

(1) 정보 유출 : 정보가 승인되지 않은 주체에게 유출되거나 공개되는 것입니다.

(2) 정보의 무결성 파기 : 무단 추가, 삭제, 수정, 파기 등으로 인해 데이터가 손실됩니다.

(3) 서비스 거부 : 정보나 기타 자원에 대한 법적 접근을 무조건 차단합니다.

(4) 불법 사용(무단 접근) : 권한이 없는 사람이나 권한이 없는 방식으로 리소스를 사용하는 경우입니다.

(5) 도청 : 합법적 또는 불법적인 다양한 수단을 이용하여 시스템 내 정보자원 및 민감한 정보를 훔치는 행위. 예를 들어, 통신 회선에서 전송되는 신호를 모니터링하거나 작동 중에 통신 장비에서 발생하는 전자기 누출을 이용하여 유용한 정보를 가로채는 경우가 있습니다.

(6) 비즈니스 흐름 분석 : 시스템의 장기적인 모니터링을 통해 통계적 분석기법을 활용하여 통신 빈도, 통신 정보 흐름 방향, 전체 통신량의 변화 등의 상황을 연구하여 가치 있는 정보와 패턴을 발굴합니다.

(7) 사칭 : 통신시스템(또는 사용자)을 속임으로써 불법이용자가 적법한 사용자인 것처럼 가장하거나, 낮은 권한을 가진 사용자가 높은 권한을 가진 사용자인 것처럼 가장하는 것입니다. 해커들은 대부분 공격을 위해 가장을 사용합니다.

(8) 우회 통제 : 공격자는 시스템 보안 결함이나 보안 취약점을 이용하여 승인되지 않은 권한이나 권한을 획득합니다. 예를 들어, 공격자는 비밀로 유지되어야 하지만 노출되는 일부 시스템 "기능"을 발견하기 위해 다양한 공격 방법을 사용합니다. 공격자는 이러한 "기능"을 사용하여 방어자를 우회하고 시스템에 침투할 수 있습니다.

(9) 권한 침해 : 특정 목적으로 시스템이나 리소스를 사용할 수 있는 권한을 부여받은 자가 이 권한을 승인되지 않은 다른 목적으로 사용하는 행위를 내부 공격이라고도 합니다.

(10) 트로이 목마 : 소프트웨어에는 실행 시 사용자의 보안을 파괴하는 감지할 수 없거나 무해한 프로그램 세그먼트가 포함되어 있습니다. 이러한 종류의 응용 프로그램을 트로이 목마라고 합니다.

(11) 트랩도어(Trap door) : 특정 시스템이나 특정 구성 요소에 특정 입력 데이터가 제공되면 보안 정책을 위반할 수 있도록 "트랩"을 설정합니다.

(12) 거부 : 이는 사용자가 게시한 메시지를 거부하거나 상대방의 편지를 위조하는 등 사용자의 공격입니다.

(13) 재생 : 차단된 통신 데이터의 합법적인 백업을 불법적인 목적으로 다시 전송합니다.

(14) 컴퓨터 바이러스 : 컴퓨터 바이러스는 컴퓨터 시스템의 작동 중에 감염되어 침해를 일으킬 수 있는 기능적인 프로그램을 말합니다. 바이러스에는 일반적으로 두 가지 기능이 있습니다. 하나의 기능은 다른 프로그램을 "감염"시키는 것이고, 다른 하나는 손상을 입히거나 공격을 심어주는 기능입니다.

(15) 인사불법행위 : 권한을 부여받은 자가 금품이나 이익을 목적으로 또는 부주의로 인해 권한이 없는 자에게 정보를 유출한 행위.

(16) 미디어 폐기 : 폐기된 디스크나 인쇄된 저장 매체에서 정보를 얻습니다.

(17) 물리적 침입 : 침입자는 물리적인 통제를 우회하여 시스템에 접근한다.

(18) 도난 : 토큰, 신분증 등 중요한 보안 물품을 도난당하는 경우.

(19) 비즈니스 사기 : 가짜 시스템 또는 시스템 구성 요소는 합법적인 사용자나 시스템을 속여 민감한 정보를 자발적으로 포기하도록 합니다.

2. 보안 시스템 아키텍처의 범위

2.1 보안 아키텍처의 범위

보안 아키텍처는 보안 방향에 따른 아키텍처의 하위 분류로, 예를 들어 운영 및 유지 관리 아키텍처, 데이터베이스 아키텍처 등이 하위 분류로 포함됩니다. 보안이 제품에 반영된다면 일반적인 제품 보안 아키텍처, 보안 기술 아키텍처, 감사 아키텍처는 세 가지 보안 방어선을 형성할 수 있습니다 .

(1) 제품 안전 아키텍처 : 제품 안전 및 품질 속성과 이들 간의 관계를 구성하는 주요 구성 요소입니다. 제품 보안 아키텍처의 목표는 외부 방어 시스템에 의존하지 않고 소스에서 자체적으로 안전한 제품을 만드는 방법입니다.

(2 보안 기술 아키텍처 : 보안 기술 시스템의 주요 구성 요소와 이들 간의 관계를 구성합니다. 보안 기술 아키텍처의 임무는 보안 인프라, 보안 도구 및 기술, 보안 구성 요소 및 지원을 포함하는 일반적인 보안 기술 인프라를 구축하는 것입니다. 시스템 등을 통해 각 제품의 보안 방어 능력을 체계적으로 강화합니다.

(3 감사 구조 : 독립적 감사 부서 또는 그것이 제공할 수 있는 위험 발견 능력. 감사 범위에는 주로 보안 위험을 포함한 모든 위험이 포함됩니다.

2.2 보안 아키텍처의 특징

보안 아키텍처에는 가용성, 무결성, 기밀성 등의 특성이 있어야 합니다 .

• 가용성은 시스템 데이터와 리소스의 손실을 방지하는 것을 의미합니다.
• 무결성이란 시스템 데이터와 리소스가 승인 없이 수정되는 것을 방지하는 것을 의미합니다.
• 기밀성이란 시스템 데이터와 리소스가 승인 없이 공개되는 것을 방지하는 것을 의미합니다.

2.3 보안 기술 아키텍처

보안 아키텍처 설계는 주로 신원 인증, 접근 제어, 콘텐츠 보안, 중복 복구, 감사 대응, 악성 코드 방지 및 암호화 기술 등을
포함하는 보안 기술 관점에서 고려할 수 있습니다.

3. 정보보호 관련 국내외 표준 및 단체

3.1 외국표준

• (1) "오렌지 북"이라고도 알려진 TCSEC(신뢰할 수 있는 컴퓨터 시스템 평가 기준)는 1985년 12월 미국 국방부에서 발행했습니다.
• (2) 영국, 프랑스, ​​독일, 네덜란드가 공동으로 작성한 ITSEC(정보 기술 보안 평가 기준).
• (3) 캐나다 신뢰할 수 있는 컴퓨터 제품 평가 기준(CTCPEC), 캐나다, 1993.
• (4) 미국 연방법(FC), TCSEC의 업그레이드 버전, 미국, 1992.
• (5) 정보 기술 보안 평가를 위한 공통 기준(The Common Criteria for Information Technology Security Evaluation)은 1993년에 미국 국가안보국(NSA)과 국립기술표준원(National Institute of Technology Standards)이 캐나다, 영국, 프랑스, ​​독일과 협력하여 편찬한 것입니다. , 네덜란드 및 기타 국가.
• (6)ISO/IEC 7498-2, 정보 처리 시스템, 개방형 시스템 상호 연결, 기본 참조 모델. 2부: 보안 아키텍처(정보 처리 시스템, 개방형 시스템 상호 통신, 기본 참조 모델, 2부: 보안 아키텍처), 국제 표준화 기구(ISO)에서 1989년 발행.
• (7) 1999년 미국 국가안보국(NSA)이 발표한 IATF(정보 보증 기술 프레임워크).
• (8)ISO/IEC 15408-1999, 정보 기술 보안 기술 정보 기술 보안 평가 기준은 원래 CC 표준을 대체합니다. 1999년 국제표준화기구(ISO)에서 발행.
• (9)IEC 61508-2010, 전기/전자/프로그래밍 가능한 전자 안전 관련 시스템의 기능적 안전, 국제전기기술위원회(International Electrotechnical Commission)에서 발행, 2010년.

3.2 국내기준

1) 표준약어의 의미
(1) GA: 국가안전산업표준규격. 중국보안기술예방인증센터가 조직하고 발표합니다.
(2)GB: 중국 국가표준화관리위원회가 조직하고 발행한 국가 표준 및 사양입니다.
(3)GJB: 국가 군사 표준 사양.

2) 주요 기술기준

• (1)GB 15834-1995 정보 처리 데이터 암호화 엔터티 식별 메커니즘.
• (2)GA163-1997 컴퓨터 정보 시스템 보안을 위한 특수 제품 분류 원칙.
• (3) GB17859-1999 컴퓨터 정보 시스템의 보안 보호 수준 분류 기준.
• (4)GB/T 9387.2-1995 정보 처리 시스템 개방형 시스템 상호 연결 기본 참조 모델 2부: 보안 아키텍처.
• (5) GB/T 20269-2006 정보 보안 기술 정보 시스템 보안 관리 요구 사항.
• (6) GB/T 20270-2006 정보 보안 기술 네트워크 기본 보안 기술 요구 사항.
• (7)GB/T 20271-2006 정보 시스템에 대한 정보 보안 기술 일반 보안 기술 요구 사항.
• (8) GB/T20272-2006 정보 보안 기술 운영 체제 보안 기술 요구 사항.
• (9) GB/T20273-2006 정보 보안 기술 데이터베이스 관리 시스템 보안 기술 요구 사항.
• (10)GB/T 20274.1-2006 정보 보안 기술 정보 시스템 보안 보증 평가 프레임워크.
• (11)GB/T 18231-2000 정보 시스템의 낮은 수준 보안.
• (12) GB/T 18237.1-2000 일반 고급 정보 기술 개방형 시스템 상호 연결 1부: 개요, 모델 및 표기법.
• (13) GB/T 18237.2-2000 정보 기술 개방형 시스템 상호 연결 일반 고급 파트 2: 보안 교환 서비스 요소 서비스 정의.
• (14)GB/T18336-2015 정보 시스템 정보 기술 보안 평가 기준.
• (15)GB/T 20438.1~7-2017 중국 국가 표준화 관리 위원회에서 발행한 전기/전자/프로그래밍 가능한 전자 안전 관련 시스템의 기능 안전.

3.3 관련 표준화 조직

• (1)국제표준화기구(ISO)
• (2)국제전기기술위원회(IEC)
• (3)중국표준화국(SAC)
• (4) 국가정보기술표준화기술위원회

4. 보안 모델

3.1 정보시스템의 보안목적

정보시스템의 보안 목표는 객체(데이터 및 프로그램 포함)에 대한 주체(사용자 및 프로세스 포함)의 접근을 통제하고 관리하는 것입니다 .
정보 시스템 보안 목표로서 다음을 달성하는 것입니다.

• 정보 시스템의 가용성을 보호합니다.
• 네트워크 시스템 서비스의 연속성을 보호합니다.
• 자원에 대한 불법적이고 무단 접근을 방지합니다.
• 침입자의 악의적인 공격과 피해를 방지합니다.
• 온라인 전송 중 정보의 기밀성과 무결성을 보호합니다.
• 바이러스로부터 보호하십시오.
• 안전관리를 실시합니다.

3.2 일반적인 보안 모델

3.2.1 상태 머신 모델

보안 상태 모델 시스템 인 State Machine Model은 항상 안전한 상태에서 시작하여 모든 마이그레이션 전반에 걸쳐 안전한 상태를 유지하므로, 보안 정책에 부합하는 보안을 갖춘 주체만이 리소스에 접근할 수 있습니다.

3.2.2 BLP 모델

BLP 모델(Bell-LaPadula 모델). 이 모델은 데이터의 기밀성을 계획하고, 기밀성에 따라 보안 수준을 나누고, 보안 수준에 따라 액세스 제어를 시행합니다.

3.2.2.1 BLP 모델의 기본 원칙:

(1) 보안 수준이 "기밀"인 주체가 보안 수준이 "일급 비밀"인 객체에 접근하면 해당 객체를 쓸 수는 있지만 읽을 수는 없습니다.
(2) 보안등급이 "기밀"인 주체가 보안등급이 "기밀"인 객체에 접근할 경우 해당 객체에 쓰기 및 읽기가 가능하다.
(3) 보안등급이 "기밀"인 주체가 보안등급이 "비밀"인 객체에 접근할 경우 해당 객체를 읽을 수는 있지만 쓸 수는 없다.

3.2.2.2 BLP 모델 보안 규칙:

(1) 단순 보안 규칙: 보안 수준이 낮은 주체는 보안 수준이 높은 객체를 읽을 수 없음(No Read Up) (
2) 스타 보안 속성: 보안 수준이 높은 주체는 읽을 수 없음 저수준 객체 쓰기 (기록 없음),
(3) 강력한 별 보안 속성: 다른 수준에 대한 읽기 및 쓰기를 허용하지 않음,
(4) 임의 보안 속성: 액세스 사용 제어 매트릭스를 사용하여 자유로운 액세스 제어를 정의합니다. 액세스 제어는 컨텐츠 관련 및 컨텍스트 관련 측면으로 구현됩니다.

3.2.3 비바 모델

Biba 모델은 정보 기밀성의 보안 수준에 관심이 없으므로 액세스 제어는 보안 수준이 아닌 무결성 수준을 기반으로 합니다.

무결성의 세 가지 목표:
(1) 승인되지 않은 사용자에 의한 수정으로부터 데이터 보호 ,
(2) 승인된 사용자에 의한 승인되지 않은 수정(무단 변경)으로부터 데이터 보호 ,
(3) 데이터의 내부 및 외부 일관성 유지 .

3.2.3.1 Biba 모델의 기본 원리

(1) 무결성 수준이 "Medium Integrity"인 주체가 무결성이 "High Integrity"인 객체에 접근할 때, 주체는 객체를 읽을 수는 있지만 쓸 수는 없으며(No Write Up), 주체의 어떤 항목도 호출할 수 없습니다. 프로그램 및 서비스. ;

(2) 무결성 수준이 "Medium Integrity"인 주체가 무결성이 "Medium Integrity"인 개체에 액세스하면 해당 개체에 읽고 쓸 수 있습니다 .

(3) 무결성 수준이 "Medium Integrity"인 주체가 무결성이 "Low Integrity"인 객체에 접근할 경우 해당 객체에 쓸 수는 있지만 읽을 수는 없습니다(No Read Down) .

3.2.3.2 Biba 모델 보안 규칙

Biba 모델은 데이터가 낮은 무결성 수준에서 높은 무결성 수준으로 흐르는 것을 방지할 수 있으며 보안 규칙은 다음과 같습니다.

(1) 스타 무결성 규칙(*-integrity Axiom): 무결성 수준이 낮은 주체는 무결성 수준이 높은 객체에 데이터를 쓸 수 없음을 의미합니다.

(2) 단순 무결성 공리(Simple Integrity Axiom): 무결성 수준이 높은 주체는 무결성 수준이 낮은 객체의 데이터를 읽을 수 없다는 의미입니다.

(3) 호출 속성 규칙: 무결성 수준이 낮은 주체는 무결성 수준이 높은 객체의 프로그램이나 서비스를 호출할 수 없음을 나타낸다.

3.2.4 CWM 모델

CWM 모델(Clark-Wilson 모델). 무결성 목표, 전략, 메커니즘을 통합하고 업무 분리 목표를 제안하며 무결성 검증 프로세스를 적용하고 은행 시스템에서 자주 사용되는 성숙한 거래 처리 메커니즘을 구현합니다.

CWM 모델은 다음과 같은 특징을 가지고 있습니다.

(1) 주체, 프로그램, 객체의 세 가지 요소를 포함하며, 주체는 프로그램을 통해서만 객체에 접근할 수 있습니다.
(2) 권한 분리 원칙, 권한이 있는 사용자에 의한 무단 수정을 방지하기 위해 기능을 여러 주제로 나눌 수 있습니다.
(3) 감사능력을 갖출 것.

3.2.5 중국 벽 모델

만리장성 모델은 다중 안보 영역에서 잠재적인 충돌을 방지하기 위해 다자간 안보 시스템에 적용되는 하이브리드 전략 모델입니다. 이 모델은 투자 은행을 위해 설계되었으며 금융 분야에서 일반적으로 사용됩니다.

3.2.5.1 만리장성 모델의 작동 원리

DAC(Discretionary Access Control)를 통해 보안 도메인을 선택하고, MAC(Mandatory Access Control)을 통해 특정 보안 도메인 내에서의 접근 제어를 완료합니다.

3.2.5.2 만리장성 모델의 보안 규칙

(1) 벽 안의 물체를 읽을 수 있습니다.
(2) 서로 다른 이해관계가 상충되는 개체를 읽을 수 있습니다.
(3) 회사의 다른 개체 및 기타 이해상충 집단의 개체에 접근한 후, 해당 개체에 대한 주체의 글쓰기가 제한됩니다.

4. 정보보호 전체 아키텍처 설계(WPDRRC 모델)

4.1 WPDRRC 정보보안 아키텍처 모델

WPDRRC(Waring/Protect/Detect/React/Restore/Counterattack) 정보 보안 모델 은 중국의 '863' 정보 보안 전문가 그룹이 제안한 중국 국가 상황에 적합한 정보 시스템 보안 시스템 구축 모델 입니다 . WPDRRC는 PDRR(Protect/Detect/React/React/Restore) 정보보안 시스템 모델을 기반으로 조기경보 및 반격 기능을 추가한 것이다. 네트워크 보안 보호 문제에 대응하여 미국은 여러 네트워크 보안 시스템 모델과 아키텍처를 제안했으며, 그중 보다 고전적인 모델에는 PDRR 모델과 P2DR 모델이 포함됩니다.

WPDRRC 모델은 중국이 제안했습니다. PDRR 모델 에서는 보안 개념이 정보 보안에서 정보 보증으로 확장되었습니다. 정보 보증의 의미는 전통적인 정보 보안 및 기밀성을 넘어 보호(Protect), 탐지(Detect), 대응(React) 및 복원(Restore)입니다. 유기적인 조합을 PDRR이라고 합니다. 모델 . PDRR 모델은 정보보안 보호를 기본으로 하여 보호를 능동적인 프로세스로 취급하며, 보안 취약점을 발견하고 적시에 수정하기 위한 탐지 방법을 사용해야 하며, 다양한 침입에 대처하기 위한 긴급 대응 조치를 취해야 합니다. 침해된 경우 이에 상응하는 조치를 취해야 하며, 정보 보안이 완전히 보장될 수 있도록 시스템을 정상 상태로 복원해야 합니다. 이 모델은 자동 오류 복구 기능을 강조합니다.

아래와 같이 WPDRRC 모델이 표시됩니다.

WPDRRC 모델은 6개의 링크와 3개의 주요 요소로 구성됩니다 .

6개 링크 에는 조기 경보, 보호, 탐지, 대응, 복구 및 반격이 포함되며 매우 순차적이고 동적이며 정보 시스템 보안 시스템의 조기 경고, 보호, 탐지 및 대응 기능을 더 잘 반영할 수 있습니다. 능력, 탄력성 및 능력 반격하기 위해.

세 가지 주요 요소 는 사람, 전략, 기술 입니다 . 사람이 핵심이고, 전략이 다리이고, 기술이 담보이며, 보안 조기경보 전략을 보안 현실로 만들기 위해 WPDRRC의 6개 링크 모든 측면에서 구현됩니다.

여기에서는 6개의 링크에 대해 다음과 같이 설명합니다. 건강 정보 콘텐츠

● W : 조기경보란 주로 원격 보안평가 시스템에서 제공하는 모의 공격 기술을 이용하여 시스템 내에 존재하고 악용될 수 있는 취약한 링크를 확인하고, 네트워크 및 정보의 보안 위험을 수집 및 테스트하여 보고하는 것을 말한다. 직관적인 방법으로 분석 후 솔루션 추천을 제공하여 네트워크의 위험 동향과 심각한 위험 지점을 세분화하여 네트워크의 전반적인 위험을 효과적으로 줄이고 주요 비즈니스와 데이터를 보호합니다.

● P : 보호는 일반적으로 성숙한 정보 보안 기술과 방법을 사용하여 네트워크 및 정보 보안을 달성합니다. 주요 내용에는 암호화 메커니즘, 디지털 서명 메커니즘, 접근 제어 메커니즘, 인증 메커니즘, 정보 은닉 및 방화벽 기술 등이 포함됩니다.

● D : 탐지는 네트워크와 시스템을 탐지 및 모니터링하여 새로운 위협과 약점을 발견하고 보안 정책을 시행합니다. 이 과정에서 침입 탐지, 악성 코드 필터링 등의 기술을 사용하여 동적 탐지 시스템과 보상 보고 조정 메커니즘을 구성하여 탐지의 실시간 특성을 향상시킵니다. 주요 내용으로는 침입탐지, 시스템 취약점 탐지, 데이터 무결성 탐지, 공격탐지 등이 있다.

● R : 대응(Response)은 보안 취약점 및 보안 이벤트를 감지한 후 시스템을 안전한 상태로 만들기 위해 적시에 올바른 대응이 이루어져야 함을 의미합니다. 이를 위해서는 차단, 격리, 보고 등의 처리 능력을 포함해 그에 상응하는 경보, 추적, 처리 시스템이 필요하다. 주요 내용에는 비상전략, 비상메커니즘, 비상수단, 침입과정분석, 보안상태평가 등이 포함된다.

● R : 복구 재해복구 시스템은 현재의 네트워크, 데이터, 서비스가 해커의 공격을 받아 손상되거나 영향을 받은 후, 가능한 한 최단 시간 내에 시스템을 정상으로 복구하기 위해 필요한 기술적 수단을 사용하는 것입니다. 주요 내용에는 내결함성, 이중화, 백업, 교체, 수리 및 복구 등이 포함됩니다.

● C : 반격이란 가능한 모든 첨단수단을 동원하여 컴퓨터범죄자의 단서 및 범죄증거를 탐지, 추출하여 강력한 증거수집능력과 합법적인 공격수단을 형성하는 것을 말한다.

4.2 정보보호 시스템 아키텍처 설계

네트워크 애플리케이션에 대한 포괄적인 이해를 통해 보안 위험, 요구사항 분석 결과, 보안 정책, 네트워크 보안 목표에 따라 보안 시스템 아키텍처 설계 작업을 수행합니다 . 특히 보안 관제 시스템에서는 물리적 보안, 시스템 보안, 네트워크 보안, 애플리케이션 보안, 관리 보안 등 5가지 측면에서 분석 및 설계 작업을 수행 할 수 있습니다.

• 물리적 보안(선행) : 환경보안, 장비보안, 미디어보안을 포함한다.
• 시스템 보안(기본) : 네트워크 구조 보안, 운영체제 보안, 응용시스템 보안을 포함한다.
• 네트워크 보안(키) : 접근 제어, 통신 기밀 유지, 침입 탐지, 네트워크 보안 검사, 바이러스 백신 등이 포함됩니다.
• 애플리케이션 보안 : 리소스 공유 및 정보 저장을 포함합니다.
• 안전 관리 : 건전한 시스템, 관리 플랫폼 및 직원 안전 인식을 포함합니다.

5. 네트워크 보안 아키텍처 설계

5.1 OSI 보안 아키텍처

OSI 는 계층 5(세션 계층)를 제외한 각 계층이 해당 보안 서비스를 제공할 수 있는 7 계층 프로토콜을 정의합니다 . 실제로 보안 서비스를 구성하는 데 가장 적합한 위치는 물리 계층, 네트워크 계층, 전송 계층, 애플리케이션 계층이며, 다른 계층에서 보안 서비스를 구성하는 것은 적합하지 않습니다.

OSI 개방형 시스템 상호 연결 보안 시스템의 5가지 보안 서비스 에는 인증, 접근 제어, 데이터 기밀성, 데이터 무결성 및 부인 방지가 포함됩니다 .

다음은 정보 보안 아키텍처의 개략도입니다.

다음은 보안 서비스와 보안 메커니즘 간의 대응 관계입니다.

OSI는 심층 방어 보안 기술 아키텍처 라고도 알려진 계층형 다중 지점 보안 기술 아키텍처를 정의합니다 . 이는 다음 세 가지 방식으로 정보 시스템 전체에 방어 기능을 배포합니다 .

• (1) 다지점 기술방어는
  상대가 내부 또는 외부의 다지점에서 표적을 공격할 수 있다는 전제하에 다음과 같은 다지점 기술방어를 통해 모든 형태의 공격에 저항하는 목적을 달성할 수 있다.
  방어는 네트워크 및 인프라, 경계방어(기존과 동일하게 트래픽 필터링, 제어, 탐지), 컴퓨팅 환경 등을 통해 수행됩니다.
  (1) 네트워크 및 인프라 . 가용성을 보장하려면 LAN 및 WAN을 서비스 거부 공격과 같은 공격으로부터 보호해야 합니다. 기밀성과 무결성을 보장하려면 이러한 네트워크를 통해 전송되는 정보와 트래픽 특성을 의도하지 않은 공개로부터 보호해야 합니다.
  (2) 경계 . 활성 네트워크 공격으로부터 보호하려면 경계는 트래픽 필터링, 제어, 침입 탐지 등 더욱 강력한 경계 방어를 제공해야 합니다.
  (3)컴퓨팅 환경 . 내부의 밀집된 분산 공격으로부터 보호하려면 호스트와 워크스테이션이 적절한 액세스 제어를 제공해야 합니다.

• (2) 계층화된 기술 방어.
  최고의 정보 보증 제품에도 약점이 있습니다. 최종 결과는 공격자가 악용할 수 있는 취약점을 발견하게 되는 것입니다. 효과적인 조치는 공격자와 대상 사이에 다중 방어 메커니즘을 사용하는 것입니다. . 이러한 공격으로 인한 성공적인 공격 가능성과 경제성을 줄이려면 각 메커니즘이 고유한 장벽을 나타내고 보호 및 탐지 방법을 모두 포함해야 합니다. 예를 들어, 외부 및 내부 경계 모두에서 침입 탐지와 함께 중첩된 방화벽을 사용하는 것은 계층화된 기술 방어의 예입니다.
  중첩된 방화벽은 침입 탐지와 함께 외부 및 내부 경계에서 사용됩니다.

• (3) 지원 인프라
  지원 인프라는 공개 키 인프라와 탐지 및 대응 인프라를 포함하여 네트워크, 경계 및 컴퓨팅 환경에서 정보 보증 메커니즘의 운영을 위한 기반이 되는 지원 인프라입니다.
  공개키 인프라와 탐지·대응 인프라를 활용해 방어하세요.
  (1) 공개 키 인프라 . 공개 키 인증서와 기존 대칭 키를 안전하게 생성, 배포 및 관리하기 위한 공통 페더레이션을 제공하여 네트워크, 경계 및 컴퓨팅 환경에 보안 서비스를 제공할 수 있습니다. 이러한 서비스는 발신자와 수신자의 무결성에 대한 신뢰성 있는 검증을 제공하고 정보의 무단 공개 및 변경을 방지합니다. 공개 키 인프라는 제어된 상호 운용성을 지원하고 각 사용자 커뮤니티에서 설정한 보안 정책과 일관성을 유지해야 합니다.
  (2) 탐지 및 대응 인프라 . 탐지 및 대응 인프라는 침입을 신속하게 탐지하고 대응합니다. 또한 다른 관련 이벤트와 함께 이벤트를 쉽게 볼 수 있는 "요약" 기능도 제공합니다. 또한 분석가는 이를 통해 잠재적인 행동 패턴이나 새로운 추세를 식별할 수 있습니다.

5.2 인증 프레임워크

인증의 기본 목적은 다른 개체가 인증된 개체의 ID를 점유하고 독립적으로 운영하는 것을 방지하는 것입니다. 인증은 엔터티가 자신의 신원을 주장하고 주체와 검증자 간의 관계 맥락에서만 의미가 있다는 보증을 제공합니다. 인증에는 두 가지 중요한 관계 배경이 있습니다. 첫째, 엔터티는 신청자가 대표하고 신청자와 검증자 사이에 특정 통신 관계(예: 엔터티 식별)가 있습니다. 둘째, 엔터티는 검증자에게 데이터 항목의 소스를 제공합니다. .

식별 방법은 주로 다음 5가지 방법을 기반으로 합니다.

(1) 비밀 비밀번호 등을 알고 있는 경우.
(2) IC 카드, 토큰 등을 소지하고 있는 것.
(3) 생물학적 특성 등 변하지 않는 특성.
(4) 신뢰할 수 있는 제3자가 설정한 인증을 신뢰합니다(재귀).
(5) 환경(호스트 주소 등).

인증서비스는 설치단계, 식별정보 수정단계, 배포단계, 취득단계, 전송단계, 검증단계, 비활성화단계, 재활성화단계, 설치취소단계로 구분 됩니다 .

5.3 접근 제어 프레임워크

Initiator가 대상에 대한 특별한 접근을 요청하면 AEF(Access Control Enforcement Facility)는 ADF(Access Control Decision Facility)에 이를 통보하며, ADF는 Initiator의 위치, 접근 시간 또는 사용 중인 특수 통신 경로 등의 컨텍스트 정보를 사용할 수 있습니다. ) 및 개시자의 대상 액세스 시도를 허용하거나 거부하는 결정을 내리기 위해 이전 결정에서 유지된 액세스 제어 결정 정보(액세스 제어 결정 정보, ADI)가 있을 수 있습니다.

5.4 기밀성 프레임워크

무결성 서비스의 목적은 정보가 승인된 사람에게만 제공되도록 보장하는 것 입니다 .

기밀성 메커니즘에는 액세스 거부를 통한 기밀성 제공과 암호화를 통한 기밀성 제공이 포함됩니다 .

5.5 무결성 프레임워크

무결성 서비스의 목적은 위협을 예방하거나 위협을 탐지하고 데이터 및 관련 속성의 무결성을 보호하는 것 입니다 .

무결성 서비스 범주 에는 무단 데이터 생성, 데이터 생성, 데이터 삭제 및 데이터 재생이 포함됩니다 .

무결성 메커니즘에는 미디어 액세스를 차단하고 무단 수정을 감지하는 두 가지 유형이 있습니다 .

5.6 부인방지 프레임워크

부인방지 서비스의 목적은 특정 사건이나 행동에 대한 증거를 제공하는 것 입니다 .

부인방지 서비스 단계는 증거 생성, 증거 전송, 저장 및 복구, 증거 검증, 분쟁 해결의 5단계 로 구분 됩니다 .

6. 데이터베이스 시스템 보안 설계

6.1 데이터베이스 무결성 설계 원칙

데이터베이스 무결성 설계를 구현할 때 다음과 같은 기본 원칙을 파악해야 합니다.

(1) 데이터베이스 무결성 제약 조건의 유형에 따라 시스템 수준 및 구현 방법을 결정 하고 시스템 성능에 미치는 영향을 사전에 고려합니다 . 일반적으로 정적 제약조건은 데이터베이스 스키마에 최대한 포함되어야 하며, 동적 제약조건은 애플리케이션에 의해 구현됩니다.

(2) 개체 무결성 제약 조건과 참조 무결성 제약 조건은 관계형 데이터베이스의 가장 중요한 무결성 제약 조건으로 , 시스템의 주요 성능에 영향을 주지 않고 최대한 적용되어야 합니다. 시스템의 사용 편의성을 대가로 일정량의 시간과 공간을 투자할 가치가 있습니다.

(3) 주의해서 사용하세요 . 현재 주류 DBMS에서 지원하는 트리거 기능 은 트리거의 성능 오버헤드가 크기 때문에 트리거의 다단계 트리거링을 제어하기 어렵고, 오류가 발생하기 쉬우므로 Before 문 수준 트리거를 사용하는 것이 가장 좋습니다.

(4) 요구사항 분석 단계에서는 무결성 제약조건에 대한 명명 규칙을 공식화해야 하며 , 영어 단어, 약어, 테이블 이름, 열 이름, 밑줄 등을 의미 있는 조합으로 인식하고 기억하기 쉽도록 노력해야 합니다. CKC_EMP_REAL_INCOME_EMPLOYEE, PK_EMPLOYEE, CKT_EMPLOYEE. CASE 도구를 사용하는 경우 일반적으로 기본 규칙이 있으며 이를 기반으로 수정하여 사용할 수 있습니다.

(5) 암시적 무결성 제약 조건과 성능에 미치는 영향 간의 충돌을 최대한 빨리 제거하려면 비즈니스 규칙에 따라 데이터베이스 무결성을 주의 깊게 테스트해야 합니다 .

(6) 처음부터 끝까지 데이터베이스의 분석, 설계, 테스트, 구현 및 조기 유지 관리를 담당하는 전담 데이터베이스 설계 팀이 있어야 합니다 . 데이터베이스 설계자는 DBMS를 기반으로 데이터베이스 무결성 제약 조건을 설계하고 구현하는 것뿐만 아니라 응용 소프트웨어에서 구현하는 데이터베이스 무결성 제약 조건을 검토하는 역할도 담당합니다.

(7) 데이터베이스 설계의 각 단계에서 작업 부하를 줄이기 위해 적절한 CASE 도구를 사용해야 합니다 . 좋은 CASE 도구는 전체 데이터베이스 수명주기를 지원할 수 있으므로 데이터베이스 설계자의 작업 효율성을 크게 향상시키고 사용자와 더 쉽게 소통할 수 있습니다 .

6.2 데이터베이스 무결성의 역할

데이터베이스 무결성은 데이터베이스 애플리케이션 시스템에 매우 중요하며 그 역할은 주로 다음 측면에 반영됩니다.

(1) 데이터베이스 무결성 제약 조건은 합법적인 사용자가 데이터베이스를 사용할 때 의미상 일관성이 없는 데이터를 데이터베이스에 추가하는 것을 방지 할 수 있습니다 .

(2) DBMS 기반의 무결성 제어 메커니즘을 사용하여 비즈니스 규칙을 구현하는 것은 정의 및 이해가 쉽고 애플리케이션의 복잡성을 줄이고 애플리케이션의 운영 효율성을 향상시킬 수 있습니다 . 동시에 DBMS 기반의 무결성 제어 메커니즘이 중앙에서 관리되므로 애플리케이션보다 데이터베이스 무결성을 달성하기가 더 쉽습니다.

(3) 합리적인 데이터베이스 무결성 설계는 데이터베이스 무결성과 시스템 성능을 모두 고려할 수 있습니다. 예를 들어, 대량의 데이터를 로드할 때 DBMS를 기반으로 하는 데이터베이스 무결성 제약 조건을 로드하기 전에 일시적으로 무효화한 후 다시 적용하면 데이터 로드의 효율성이 영향을 받지 않고 데이터베이스의 무결성을 보장할 수 있습니다. 데이터베이스를 보장할 수 있습니다.

(4) 응용 소프트웨어의 기능 테스트 에서 완벽한 데이터베이스 무결성은 응용 소프트웨어 오류를 가능한 한 빨리 감지하는 데 도움이 됩니다 .

(5) 데이터베이스 무결성 제약 조건은 열 수준 정적 제약 조건, 튜플 수준 정적 제약 조건, 관계 수준 정적 제약 조건, 열 수준 동적 제약 조건, 튜플 수준 동적 제약 조건, 관계 수준 동적 제약 조건 등 6가지 범주로 나눌 수 있습니다. 동적 제약 조건은 일반적으로 응용 프로그램 소프트웨어에 의해 구현됩니다. 서로 다른 DBMS에서 지원하는 데이터베이스 무결성은 기본적으로 동일합니다.

7. 시스템 아키텍처 취약점 분석

7.1 시스템 아키텍처의 취약성 구성요소

시스템 아키텍처 취약성 에는 물리적 장비 취약성, 소프트웨어 취약성, 인사 관리 취약성, 규칙 및 규정 취약성, 보안 정책 취약성 등이 포함됩니다 .

IBM의 소프트웨어 결함 분류는 다음과 같습니다.

7.2 일반적인 아키텍처의 취약점 표현

소프트웨어 아키텍처 취약점은 일반적으로 소프트웨어 아키텍처의 스타일 및 모델과 관련이 있으며, 다양한 스타일과 모델을 가진 소프트웨어 아키텍처는 취약점 발현 및 특성이 매우 다르며, 취약점 문제를 해결하기 위해 고려해야 할 요소와 취해야 할 조치도 매우 다릅니다. ...

7.2.1 계층화된 아키텍처

계층화된 아키텍처는 엔터프라이즈 애플리케이션 소프트웨어 아키텍처 설계에 널리 사용됩니다. 대부분의 계층화된 아키텍처 패턴에는 일반적으로 프레젠테이션 계층, 비즈니스 계층, 지속성 계층 및 데이터베이스 계층의 네 가지 계층이 포함됩니다. 계층형 아키텍처는 응용 시스템을 여러 계층으로 직교적으로 나누고, 각 계층은 문제의 일부만 해결하며, 각 계층의 협업을 통해 전체 솔루션을 제공합니다. 계층화된 아키텍처의 선명함

약점은 주로 두 가지 측면에서 나타납니다.

(1) 레이어 간 취약점 . 특정 하위 계층에 오류가 발생하면 전체 프로그램이 정상적으로 실행되지 않을 수 있는데, 예를 들어 일부 데이터 오버플로, 널 포인터 및 널 개체에 대한 보안 문제가 발생할 수 있으며 잘못된 결과가 나올 수도 있습니다.

(2) 계층 간 통신의 취약점 . 시스템을 상대적으로 독립적인 여러 계층으로 분리하려면 계층 간 통신 메커니즘을 도입해야 합니다. 객체 지향 방법을 사용하여 설계된 시스템에는 일반적으로 세분화된 개체 수가 많고 메시지도 많습니다. 상호 작용 - 개체 멤버 호출 행동 양식. 원래 "간단한" 작업은 이제 계층별로 전달되어야 하므로 필연적으로 성능 저하가 발생합니다.

7.2.2 C/S 아키텍처

C/S 아키텍처는 클라이언트와 서버 구조입니다. C/S는 서버부분과 클라이언트부분으로 나누어집니다. 서버 부분은 여러 사용자가 공유하는 정보 및 기능으로 공유 데이터베이스의 동작 제어 등 백그라운드 서비스를 수행하고, 클라이언트 부분은 사용자 전용으로 프론트엔드 기능 실행을 담당하며 강력한 기능을 가지고 있습니다. 오류 프롬프트 및 온라인 도움말 기능이 있으며 서브루틴 간에 자유롭게 전환할 수 있습니다.

C/S 아키텍처의 취약성은 주로 다음 측면에 반영됩니다.

(1) 클라이언트 소프트웨어의 취약점 . C/S 아키텍처 시스템은 특정 클라이언트 소프트웨어를 설치한 사용자만이 사용할 수 있으며, 클라이언트 소프트웨어가 사용자의 컴퓨터에 설치되어 있다는 것만으로도 시스템은 프로그램 분석 및 데이터 가로채기 등의 보안 위험에 직면하게 됩니다.

(2) 네트워크 개방성의 취약성 . 현재 많은 전통적인 C/S 시스템은 여전히 ​​2계층 구조를 채택하고 있습니다. 즉, 모든 클라이언트가 서버 측의 데이터를 직접 읽고 클라이언트 측 데이터의 사용자 이름, 비밀번호 및 기타 치명적인 정보를 포함한다는 의미입니다. 이로 인해 시스템에 문제가 발생하고 안전 위험이 발생합니다. 그러한 시스템이 인터넷에 배치되면 서버 측은 인터넷상의 모든 사용자에게 공개됩니다.

(3) 네트워크 프로토콜의 취약성 . C/S는 다양한 네트워크 프로토콜을 사용하거나 프로토콜을 맞춤화할 수 있으므로 이러한 관점에서 C/S 아키텍처의 보안이 보장됩니다. 그러나 C/S 아키텍처는 사용자와 언제든지 통신하기에 편리하지 않으며(주로 데이터 패킷 공유에 편리하지 않기 때문), C/S 아키텍처 소프트웨어는 데이터 보안을 보호하는 데 본질적인 단점이 있습니다. C/S 아키텍처 소프트웨어의 데이터 분산 특성으로 인해 클라이언트 측에서 발생하는 화재, 도난, 지진, 바이러스 등은 끔찍한 데이터 킬러가 됩니다.

7.2.3 B/S 아키텍처

B/S 아키텍처는 브라우저/서버 구조 모델로서 웹 기술을 기반으로 한 새로운 경영정보시스템 플랫폼 모델로, 일반 브라우저를 이용하여 복잡한 특수 소프트웨어로만 구현할 수 있는 강력한 기능을 구현합니다. B/S 아키텍처의 장점은 특별한 소프트웨어를 설치하지 않고도 어디서나 운영할 수 있다는 점이며, 인터넷 접속이 가능한 컴퓨터만 있으면 클라이언트는 유지 관리가 필요 없으며 시스템 확장이 매우 쉽고 데이터가 데이터베이스 서버에 중앙 저장되므로 데이터 불일치가 없습니다.

B/S 아키텍처의 취약성은 주로 다음과 같이 나타납니다.

시스템이 HTTP 프로토콜을 사용하는 경우 B/S 아키텍처는 C/S 아키텍처보다 바이러스 침입에 더 취약하며 최신 HTTP 프로토콜은 보안이 향상되었지만 여전히 C/S에 비해 취약합니다.

7.2.4 이벤트 중심 아키텍처

이벤트 중심 아키텍처는 널리 사용되는 분산 비동기 아키텍처로 확장성이 높은 프로젝트에 적합한 널리 사용되는 분산 이기종 아키텍처 모델로 유연성이 높으며 고도로 분리된 단일 목적 비동기 수신 이벤트 처리로 구성됩니다. 컴포넌트와 이벤트로 구성됩니다. 손질. 이벤트 중심 아키텍처에는 일반적으로 중재자 구조와 브로커 구조라는 두 가지 토폴로지가 있습니다. 중재자 구조는 일반적으로 이벤트의 여러 단계를 중간 역할을 통해 지시하고 조정해야 하는 상황에 적합하고, 브로커 구조는 다음과 같은 상황에 적합합니다. 이벤트는 연쇄 관계이므로 중간 캐릭터 상황이 필요하지 않습니다.

이벤트 중심 아키텍처의 취약점은 주로 다음과 같이 나타납니다.

(1) 구성 요소의 취약성 . 구성 요소는 시스템 제어 능력을 약화시키며, 구성 요소가 이벤트를 트리거하면 해당 이벤트에 응답하는 다른 구성 요소와 각 구성 요소의 실행 순서를 결정할 수 없습니다.

(2) 구성 요소 간에 교환되는 데이터의 취약성 . 컴포넌트는 데이터 교환 문제를 잘 해결할 수 없으며, 이벤트가 발생하면 하나의 컴포넌트가 다른 컴포넌트에 매개변수를 전달해야 할 수도 있고, 데이터의 양이 많을 경우 어떻게 효과적으로 전달할 것인지가 취약점 문제이다.

(3) 구성 요소 간의 논리적 관계가 취약합니다 . 이벤트 아키텍처는 시스템 구성 요소 간의 논리적 관계를 더욱 복잡하게 만듭니다.

(4) 이벤트 구동은 프로그래밍 로직에 의해 결정되는 무한 루프에 쉽게 들어갈 수 있습니다.

(5) 높은 동시성 취약성 . 이벤트 기반은 CPU 자원을 효율적으로 활용할 수 있지만 높은 동시성 이벤트 처리로 인한 시스템 응답 문제가 있으며, 높은 동시성으로 인해 잘못된 시스템 데이터, 데이터 손실 등이 쉽게 발생할 수 있습니다.

(6) 고정 프로세스의 취약성 . 이벤트 중심의 대응 프로세스는 기본적으로 고정되어 있기 때문에 제대로 운영되지 않을 경우 보안 문제가 발생하기 쉽습니다.

7.2.5 MVC 아키텍처

MVC 아키텍처는 Model, View, Controller의 약자로 Model, View, Controller에 따라 애플리케이션의 입력, 처리, 출력 과정을 분리합니다. 뷰 레이어, 컨트롤 레이어..

MVC 아키텍처의 취약성은 주로 다음과 같이 나타납니다.

(1) MVC 아키텍처의 복잡성으로 인해 취약성이 발생합니다 . MVC 아키텍처는 시스템 구조와 구현의 복잡성을 증가시킵니다. 예를 들어, 단순한 인터페이스가 MVC 방식을 엄격히 따르고 모델, 뷰, 컨트롤러를 분리한다면 구조의 복잡성이 증가하고 너무 많은 업데이트 작업이 발생하며 작업 효율성이 저하될 수 있습니다.

(2) 뷰와 컨트롤러 사이의 긴밀한 연결이 취약합니다 . 뷰와 컨트롤러는 별개이지만 밀접하게 연관된 구성요소로, 컨트롤러가 없으면 뷰의 적용이 매우 제한됩니다. 그 반대의 경우도 있으므로 독립적인 재사용이 불가능합니다.

(3) 모델 데이터에 대한 비효율적인 접근에 대한 뷰의 취약성 . 모델 작업 인터페이스에 따라 충분한 표시 데이터를 얻기 위해 뷰를 여러 번 호출해야 할 수도 있습니다. 변경되지 않은 데이터에 불필요하게 자주 액세스하면 운영 성능이 저하됩니다. MVC 아키텍처의 취약점은 주로 호출자에 대한 보안 검증 방법이 부족하고 데이터 전송에 대한 보안이 부족하다는 점에 반영된다고 할 수 있으며, 이러한 결함은 MVC가 상대적으로 취약하고 공격에 취약한 주요 원인이기도 합니다.

7.2.6 마이크로커널 구조

마이크로커널 아키텍처는 일반적으로 커널과 통합되는 시스템 서비스 계층을 분리하고 시스템 확장성을 달성하고 환경 요구 사항에 더 잘 적응하기 위해 필요에 따라 이를 선택적으로 만드는 간소화된 형태의 커널을 나타냅니다. 마이크로커널 아키텍처는 플러그인 아키텍처 패턴이라고도 하며 일반적으로 커널 시스템과 플러그인으로 구성됩니다.

마이크로커널 아키텍처의 취약점은 주로 다음에 반영됩니다.

(1) 마이크로커널 아키텍처는 전반적인 최적화를 제대로 수행하기 어렵습니다 . 마이크로커널 시스템의 핵심 상태는 가장 기본적인 시스템 작업만 구현하므로 커널 외부의 외부 프로그램이 독립적으로 작동하면 시스템이 전체적으로 좋은 최적화를 수행하기 어렵습니다.

(2) 마이크로커널 시스템의 프로세스 간 통신 오버헤드도 단일 커널 시스템보다 훨씬 큽니다 . 전체적으로 현재 하드웨어 조건에서 마이크로커널의 효율성 손실은 구조적 이득보다 적습니다.

(3) 통신손실률이 높다. 마이크로커널은 시스템을 작은 기능 블록으로 나누어 설계의 어려움을 줄이고 시스템 유지 및 수정을 용이하게 하지만, 통신으로 인한 효율성 손실이 문제가 된다.

7.2.6 마이크로서비스 아키텍처

마이크로서비스 아키텍처는 모놀리식 아키텍처 애플리케이션을 작은 서비스 집합으로 나누는 것을 옹호하는 아키텍처 패턴으로, 서비스는 서로 조정하고 협력하여 사용자에게 궁극적인 가치를 제공합니다. 마이크로서비스 아키텍처의 각 서비스는 자체 독립 프로세스에서 실행되며 서비스는 경량 통신 메커니즘을 사용하여 서로 통신합니다. 각 서비스는 특정 비즈니스를 중심으로 구축되었으며 프로덕션 환경, 프로덕션과 유사한 환경 등에 독립적으로 배포될 수 있습니다.

마이크로서비스 아키텍처의 취약성은 주로 다음에서 나타납니다.

(1) 개발자는 분산 시스템의 복잡한 구조를 처리해야 합니다.

(2) 개발자는 서비스 간의 통신 메커니즘을 설계하고 메시지 전달이 느리거나 사용할 수 없는 등 로컬 실제 문제를 처리할 수 있는 코드를 작성해야 합니다.

(3) 서비스 관리의 복잡성: 프로덕션 환경에서는 다양한 서비스 인스턴스를 관리해야 하므로 개발팀의 전반적인 조정이 필요합니다.

8. 보안 아키텍처 설계 실습

8.1 전자상거래 시스템의 보안 설계

특정 전자상거래 시스템인 고성능 RADIUS를 사용하여 전자상거래 시스템 보안 설계의 기본 원리와 설계 방법을 설명한다.

전자상거래 시스템의 보안 설계 원칙 소개:

AAA(Authentication, Authorization and Accounting)는 광대역 네트워크 액세스 서버에서 실행되는 클라이언트 프로그램입니다. AAA는 인증, 권한 부여, 감사의 세 가지 보안 기능을 구성하기 위한 일관된 프레임워크를 제공하며 실제로는 네트워크 보안 관리입니다. 여기서 네트워크 보안이란 주로 어떤 사용자가 네트워크 서버에 접근할 수 있는지, 네트워크 자원을 사용하는 사용자를 어떻게 계정하는지 등의 접근 제어를 의미합니다. 다음은 확인, 승인 및 계정 기능을 간략하게 소개합니다.

(1) 인증: 사용자가 접근 권한을 얻을 수 있는지 확인하며, 인증 정보에는 사용자 이름, 사용자 비밀번호, 인증 결과가 포함됩니다.
(2) 승인: 승인된 사용자가 사용할 수 있는 서비스로, 승인에는 서비스 유형 및 서비스 관련 정보가 포함됩니다.
(3) 감사(회계): 사용자의 네트워크 자원 사용, 사용자 IP 주소, MAC 주소 마스크 등을 기록합니다.

RADIUS(원격 인증 전화 접속 사용자 서비스)

RADIUS는 가장 널리 사용되는 보안 수준이 높은 인증, 권한 부여, 감사 프로토콜(Authentication, Authorization, Accounting, AAA)로 고성능, 높은 확장성을 가지며 다양한 프로토콜로 구현이 가능합니다 .

RADIUS는 일반적으로 프로토콜 논리 계층, 비즈니스 논리 계층 및 데이터 논리 계층의 세 가지 계층으로 구성됩니다 .

(1) 프로토콜 로직 레이어 : 포워딩 엔진과 동등한 배포 및 처리 기능을 수행합니다.
(2) 비즈니스 로직 계층 : 인증, 승인, 감사 등 세 가지 유형의 비즈니스와 해당 서비스 프로세스 간의 통신을 구현합니다.
(3) 데이터 논리 계층 : 통합 데이터 액세스 에이전트 풀을 구현하고, 데이터베이스 의존성을 줄이고, 데이터베이스 압력을 줄이고, 시스템의 데이터 적응성을 향상시킵니다.

그림에 표시된 것처럼 RADIUS 소프트웨어 아키텍처의 핵심 논리는 다음과 같습니다.

8.2 하이브리드 클라우드 기반 산업 보안 아키텍처 설계

하이브리드 클라우드는 퍼블릭 클라우드와 프라이빗 클라우드를 결합합니다 . 하이브리드 클라우드 기반 산업안전 생산관리 시스템에서는 제품 설계, 데이터 공유, 공장 내 생산 통합 등을 프라이빗 클라우드를 이용해 구현한다. 퍼블릭 클라우드는 기업 본사와 스마트공장 간 업무관리, 조정, 통계분석 등에 활용된다. 전체 생산 관리 시스템 아키텍처는 장비 계층, 제어 계층, 설계/관리 계층 및 애플리케이션 계층으로 구분되는 계층적 아키텍처를 채택합니다 .

그림과 같이 하이브리드 클라우드 기반의 안전한 생산관리 시스템 아키텍처는 다음과 같습니다.

(1) 장비 계층 : 스마트 센서, 스마트 기기, 산업용 로봇 및 기타 생산 장비를 포함한 스마트 공장 생산 장비를 포함합니다.
(2) 제어 계층 : 감시 제어 및 획득 시스템(SCADA), 분산 제어 시스템(FCS), 프로그래밍 가능한 컨트롤러(PLC), 인간-기계 인터페이스(HMI) 및 기타 온-머신 인터페이스를 포함한 지능형 장비 제어를 위한 자동 제어 시스템을 포함합니다. 사이트 제어 프로그램.
(3) 설계/관리 : 스마트 팩토리의 모든 제어 개발, 업무 제어, 데이터 관리 관련 시스템 및 기능을 모아 데이터 통합 ​​및 응용을 구현한다.
(4) 애플리케이션 계층 : 데이터 처리 및 관리를 포함한 클라우드 플랫폼에서의 정보 처리, 맞춤형 비즈니스, 협업 비즈니스, 제품 서비스 등 데이터와 산업 애플리케이션의 결합.

하이브리드 클라우드 기반 산업안전 생산관리 시스템을 설계할 때 고려해야 할 보안 문제는 다음과 같습니다.

• 장치 보안
• 사이버 보안
• 보안 제어
• 애플리케이션 보안
• 데이터 보안

일련의 기사 디렉토리를 입력하려면 클릭하세요.