[소공 목차]

 

공공 소프트웨어 사업 영향평가 제도

 

1. SW 산업 생태계의 영향을 평가하는, 공공 SW 사업 영향 평가 제도

 1)  공공 SW 사업 영향 평가제도 개요

  • 국가기관등에서 소프트웨어사업의 예산편성, 발주, 소프트웨어 배포 및 서비스 제공을 추진하는 경우 민간 소프트웨어시장침해 등 소프트웨어 산업 생태계에 미치는 영향을 검토하여 사전 조정하는 소프트웨어 영향평가제도에 대한 가이드를 개발 및 보급하는 제도
  • 공공과 민간 간 불필요한 경쟁 및 SW산업 위축을 방지하기 위해 공공 정보화 사업의 기획단계에서 민간 시장 침해 등 SW 산업 생태계에 미치는 영향을 평가하여 개선 의견을 제시하는 제도

 2) 법적 근거

  • 소프트웨어진흥법 제43조(소프트웨어사업 영향평가), 동법 시행령 35조, 36조, 37조
  • 소프트웨어사업 계약 및 관리감독에 관한 지침 제5조, 제6조

 3) 도입 배경

도입 배경 설명
공공기관의 SW 무상배포에 관한 문제 제기 - 일부 공공기관이 SW 또는 정보시스템을 개발하여 무상 제공함에 따라 민간시장을 위축시켜 SW 산업육성을 저해한다는 산업계의 문제제기
공공기관 자체 직접적으로 대국민서비스 앱을 직접 개발(무료배포) - 민간의 유사 서비스와 불필요한 경쟁 발생 및 민간시장 축소
  • 정부-민간 SW 사업 중복, 민간 업체 도산 등의 문제 발생, 선순환 생태계 구축을 위해 시행

 

2. 공공 SW 사업 영향평가 제도 평가 절차

 1) 공공 SW 사업 영향 평가제도 평가 절차

  • 평가 결과에 따라 사업계획 변경 또는 사업 재검토 수행
  • 평가 결과에 따라 단계적으로 민간 이양 또는 사업 중지 수행

  • 민간 SW  시장 침해 가능성 및 사업의 필요성 및 공공성을 위주로 평가 수행

 2) 공공 SW사업 영향 평가제도 평가 기준

  • 평가 결과
구분 내용
민간시장 침해 가능성 없음 - 평가 결과 민간시장 침해 가능성이 없어 사업추진 가능
민간 시장 침해 가능성 있음 민간시장 침해 최소화 - 평가 결과 민간시장 침해 가능성이 있어 민간시장에 침해가 되지 않도록 유의하여 사업 추진
사업 재검토 - 평가 결과 민간시장 침해 우려가 매우 높아 사업 계획의 변경 또는 중지

 

3. 공공SW 사업 영향평가 단계별 활동

 1) 공공 SW 사업 영향평가 단계별 주요 활동

단계 주요활동 참고자료
소프트웨어 사업 기본정보 작성 - 소프트웨어사업의 기본정보를 확인하여 작성하는 단계로 사업기본정보(사업명, 주요 사업내용, 사업기간), 영향평가 단계, 사업 구분을 분류하여 작성 - 사업추진계획서
- 제안 요청서
운영계획 검토 - 운영기관 또는 사용자의 공동 사용 여부 등 소프트웨어 사업의 운영 계획을 분석하여 작성 - 사업추진계획서
- 운영계획안
민간 소프트웨어 시장 침해 가능성 검토 - 소프트웨어사업의 주요 기능과 동일·유사한 민간 소프트웨어가 존재하는지를 확인 - 사업추진계획서
- 기능 요구사항
- 제안 요청서
- 민간 소프트웨어 현황 정보 검색
사업의 필요성 및 공공성 검토 - 주요 기능이 동일·유사한 민간 소프트웨어가 있음에도 불구하고 해당 사업을 추진해야만 하는 필요성과 공공성에 대해 기재한 - 대상 SW 규정 관련 법령
- 국가안보 점검 기준
- 공공데이터 활요 공공서비스 제공 및 정비 가이드라인
종합의견 작성 - 단계별 검토 내용을 토대로 소프트웨어사업의 민간 소프트웨어 시장 침해 가능성을 종합적으로 판단하여 작성
- 민간소프트웨어시장 침해 가능성이 있음에도 추진하여야 하는 경우 민간 소프트웨어 시장 침해를 완화할 방안을 작성
- 민간 소프트웨어시장 침해가능성이 있으며 사업의 필요성 및 공공성이 낮은 경우 사업을 재검토		 - 각 단계별 검토 내용

 

2) 공공 SW 사업 영향평가 항목

유형 평가항목 설명
기관 공동사용형 SW 산업계의 파급 효과 - 정부의 SW 개발 및 배포가 시장에 미치는 영향을 정성평가
사업추진의 필요성 - 사업의 기획단계에서 여러 대안을 충실히 검토했는지와 사업 추진의 타당성(필요성, 시급성, 효과성 등)에 대해 정성평가
대국민 서비스형 민간 유사서비스 침해여부 - 매우 침해 : 핵심기능과 수요계층이 유사 서비스 2개 이상
- 침해함 : 핵심기능과 수요계층이 유사한 서비스 1개 존재
- 침해 없음 : 핵심기능과 수요계층이 유사한 서비스 없음
추진사업의 공공성 - 높음 : 민간대체가 힘든 사업으로 공공에서 수행해야하는 서비스
- 낮음 : 민간대체가 가능한 서비스

 

 

  • 소프트웨어 사업 영향 평가 가이드라인 : https://www.swit.or.kr/download.do?fileName=/202104/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%EC%82%AC%EC%97%85%20%EC%98%81%ED%96%A5%ED%8F%89%EA%B0%80%20%EA%B0%80%EC%9D%B4%EB%93%9C%EB%9D%BC%EC%9D%B8%EB%82%B4%EC%A7%80(2021)%EC%B5%9C%EC%A2%85.pdf

'메가노트 > 토픽과제(정리)' 카테고리의 다른 글

블랙박스, 화이트박스 테스트(이강욱 선임님)  (0) 2022.10.08
사업타당성 평가(이재용 부장님)  (0) 2022.10.08
Agile방법론(이상희 부장님)  (0) 2022.10.08
반복적 개발모델(문경숙 수석님)  (0) 2022.10.08
소프트웨어공학  (0) 2022.10.08

[소공 목차]

 

1. Agile 방법론 개요

1) Agile 정의

  • 프로세스보다는 변화에 대응을 위한 사람이 중심이 되어 요구사항 변경에 대해 유연하고 신속하게 적응하면서 시스템을 개발할 수 있는 반복적 방법론
  • 효율적인 제품, SW 개발을 위해 절차보다는 사람과 제품에 집중하여 낭비를 제거하고 고객의 요구사항을 보다 유연하고 신속하게 반영하기 위한 방법론
  • 특정 개발 방법론을 가리키는 말은 아니고, '애자일(=기민한, 좋은 것을 빠르고 낭비없게 만드는 것)' 개발을 가능하게 해주는 다양한 방법론 전체를 말함

 

2) Agile 방법론 특징

특징 설명
애자일에 적합한 환경 고객 요구사항이 자주 변경되는 경우 애자일 방법론이 적합
고객 참여도 고객 프로세스에 협력하기 때문에 고객과 신속한 피드백이 가능
업무 효율화 프로젝트를 여러 부분으로 나누어 점진적으로 개발하여 신속하고 반복된 주기로 수행
소규모에 적합 요규사항이 명확하지 않을 경우 또는 소규모 개발에 적합한 소프트웨어 방법론

 

2. Agile 방법론 등장 배경 및 시기

1) Agile 방법론 등장배경

SW 개발 환경 변화
- 정보시스템에 대한 사용자 요구 다양해지고, 정보시스템 수명주기 짧아짐
- 정보시스템의 적시성(time-to-market)과 Product의 적시 배포(Release)가 중요해짐
개발 방법론 한계
- 문서위주, 절차중심의 방법론은 변화에 신속한 적응이 어려움
- 변화에 빠르게 적용하고 효율적으로 개발할 수 있는 방법론이 필요
- 소규모 및 중간규모 시스템에 무거운 계획 기반 기법 적용 시 오버헤드가 너무 커짐

2) Agile 방법론 등장 시기

 

3. Agile 선언문 및 원칙

1) Agile 선언문

  The Manifesto for Agile Software Development

·  Individuals and interactions over processes and tools

·  Working software over comprehensive documentation

·  Customer collaboration over contract negotiation

·  Responding to change over following a plan

가치
지향
설명
개인과 상호작용
 소통중시 공정과 도구보다 개인과 상호작용을 강조
작동하는 소프트웨어
 실무적 관점 포괄적인 문서보다 작동하는 소프트웨어에 가치를 둠
고객과의 협력
 협동 중시 계약 협상보다 고객과의 협력에 가치를 둠
변화에 대응
 유연성 계획을 따르기 보다 변화에 대응하는 것에 가치를 둠

2) Agile 12 원칙

구분 12가지 원칙 설명
고객가치 고객만족 추구 - 빠른 배포와 피드백 반영, 고객의 만족도 향상
요구사항 변경 수용 - 고객 요구 변경 인정 및 대응을 위한 유연성
짧은 배포 간격 - 도구 등을 통해 빠른 배포, 고객 피드백 반영
소통 현업-개발자간 일일 의사소통 - 담당자와 개발자 간의 소통을 통한 업무 효율화
동기부여된 사람들 중용/지원 - 동기 부여된 팀원을 중용 및 환경 지원
면대면 대화 - Daily Meeting등을 통한 면대면 대화
개발 작동하는 소프트웨어로 진도 측정 - 직접 SW의 기능/비기능적 요소 및 진행관리
지속 가능한 개발 장려 - 지속 가능한 개발 및 프로젝트 진행 장려
좋은 기술, 설계 관심 - 우수한 기술, 아키텍처 중시 및 공유
추구 단순성 추구 - 목표 업무와 연관 없는 일들을 최소화
자기 조직화 팀 - 책임감 부여, 생산성 행샹를 위한 자기조직적 팀
정기적 효율성 제고 - 스프린트 리뷰를 통해 다음 스프린트에 반영 할 수 있는 요소 적용

 

4. Agile 조직 및 회의 체계

1) Agile 조직

조직 구성 역할
TEAM PO(Project Owner) 업무의 우선순위를 정하고 백로그 관리
SM(Scrum Manager) 팀의 사람 관리를 하며 실제 팀의 실행을 리딩
Developer 개발자
Designer 디자이너
COP PO COP 비즈니스 목표와 의존성에 대해 논의
SM COP 실행시 팀 간 의존성이 있는 업무에 대해 확인 및 개선
Design COP 디자인 가이드, 시안 리뷰 및 피드백
Tech COP 기술적 Practice 공유

2) Agile 회의 체계

모임 구분 설명
Agile COP (Community of Practice) Meeting COP 구성 원칙 - 같은 스킬을 가지고 있는 유사 직군의 멤버들의 가상 조직으로 주기적으로 모임 진행
구성원의 역할 및 특징 - 각 직군의 팀 리더들이 기술적인 스킬, 문제점, 표준/가이드화 논의
- 각 팀의 Best Practice를 공유
- Tech COP, PO COP, SM COP, Design COP 등이 운영
Agile Circle Circle 구성 원칙 - 팀 업무 이외에 별도의 이슈/목적을 가지고 업무수행이 필요한 경우 임시적으로 구성되는 조직
구성원의 역할 및 특징 - Cross-function한 이슈 중심의 팀으로 팀 구성시 목적을 분명히 하고, 정기적/부정기적으로 모임을 가지다. 단, 목적이 달성되면 해당 Circle은 해체
Agile 조직 특징 - Cross Function 팀: 목적을 달성하기 위해 조직되고 목적 달성하면 해체
- 팀장이 없음: 보고하는 대상이 없고 팀이 Daily Scrum을 통해 업무 공유
- 제한 인원(9명): 구성원 많아지면 Comm.이 어렵고 관료화 가능성 높음
- QA조직없음: 제품의 품질은 Agile 팀 내에서 책임을 지고 준수

 

5. Agile 방법론  유형

유형 내용
SCRUM - 사용자의 요구사항을 만족시키기 위해 프로토타입을 반복, 점진적으로 개발하는 Agile 방법론
- 프로젝트 관리를 위한 애자일 방법론으로서 스프린트(Sprint)라는 통상 4~6주 정도의 잘 정의된 개발주기를 가지며 개발 효율성을 극대화할 수 있는 환경제공
- 투명성(Transparency), 타임박싱, 커뮤니케이션 중심, 경험주의 모델
Kanban - 적시개발(just-in-time)을 지원하는 방법론으로 매우 적은 규칙을 가지고 있는 Agile 방법론
- 칸반보드를 통해 개발공정을 시각화 하고 개발제안(WIP) 이용해 Workflow 상의 공정을 관리하고 최적화하여 적시개발(Just in Time Development)를 지원하는 Agile 방법론
- Workflow 시각화, WIP제한, 소요시간 측정 및 최적화
XP (eXtreme Programing) - 의사소통 개선, 즉각적인 피드백에 의해 단순 코딩하여 소프트웨어의 품질을 높이기 위한 방법
- 개발조직이 기반이 되는 중소규모 팀에 적합한 경량화된 개발방식
- 협업, 빠른 소프트웨어 구현, 매우 기술적인 개발 방식을 강조하는 방법론
Lean - TPS(Toyota Production System)를 벤치마킹하여 재정립한 경영방법론을 소프트웨어 개발에 적용한 개발 방법론
- 80년 도요타 시스템의 린 생산방식을 소프트웨어 개발에 적용
- 파레토법칙에 의거하여 개발에 정말 중요한 20%에 집중하고 낭비되는 요소(가외기능, 혼란, 경계 넘어가기)를 제거

 

6. Agile 방법론 장단점

1) Agile 방법론 장점

장점 설명
ROI 증대 - 고객들에게 가치 있는 기능들을 빠르고 안정적으로 전달
Delivery Time 감소 - 요구사항의 변화를 유연하게 수용함으로써 Time to Market 실현
창의성 향상 - 팀 자율성 강화를 통한 업무만족도와 창의성 향상
생산성 향상 - 불필요한 산출물 제거 및 팀 협업 강화
제품 품질 향상 - 고객의 주기적 피드백 및 빈번한 테스트

 

2) Agile 방법론 단점

단점 내용
체계적인 문서화
및 지침 부족		 - Agile 프로세스 적용을 지원하는 문서화나 구체적인 지침 부족
- 전체 제품에 대한 통합과 테스팅에 대한 가이드가 부족
요구사항 변경에
의한 오버헤드		 - 비기능적인 요구사항에 대한 고려가 부족
- 요구사항의 잦은 변경에 따른 테스트 수행노력 증가
사업 관리 부분 미흡 - 측정지표가 개발자 위주로 상위관리자의 요구를 충족하기 충족하기 어려움
- 프로젝트 리스크 관리 (Risk management)에 대한 고려 부족
감리 대응 문제 - 기존 방법론에 비해 적은 문서량, 감리 기준에 부합되지 않는 산출물로 이슈 발생

 

 7. Agile 과 전통적 개발 방법론 비교

구분 애자일 개발 방법론 전통적인 개발 방법론
계획 수립 - 유동적인 범위 및 상세 요구사항 조정
- 주기적인 상세계획		 - 확정된 범위, 초기에 상세 요구사항 확정, 초기 일정계획 수립
개발 및 테스트 - 이터레이션 단위로 실행 소프트웨어를 전달(적시설계/개발) - 분석/설계/구현/테스트를 순차적으로 수행
프로세스 View - 유연하고 간소함
- 프로젝트 상황에 따라 주기적 조정		 - 정형화되고 상세화됨
업무 수행 형태 -  Self-Organizing 팀
- 팀 중심 업무 수행(Collective Ownership)		 - 관리자 주도적 명령과 통제
- 개인단위로 업무 수행
조직 -  Cross-Functional Team
- 전문가가 다기능을 수행		 - Functional Team
- 분업화되고 역할이 한정
팀관리 - 업무몰입 및 코칭, 팀평가 - 지시 및 감시, 경쟁, 개별 평가
문서화 - 경량 프로세스 및 문서화보다 코드 강조 - 중량 프로세스, 상세한 문서화 강조
성공요소 - 고객 가치 전달 - 계획 준수

 

8. 현대 Agile 방법론

1) Agile 원칙 비교(2001 vs. 2015)

2) 현대 Agile 원칙과 프랙티스

 

'메가노트 > 토픽과제(정리)' 카테고리의 다른 글

사업타당성 평가(이재용 부장님)  (0) 2022.10.08
공공소프트웨어 사업영향평가제도(안혜진 선임님)  (0) 2022.10.08
반복적 개발모델(문경숙 수석님)  (0) 2022.10.08
소프트웨어공학  (0) 2022.10.08
무선랜 보안(배준호)  (1) 2022.10.04

[소공 목차]

 

 

1. 반복적 개발 모델

-. 사용자의 요구사항 일부분 혹은 제품의 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델(폭포수+프로토타입, 각각의 iteration은 mini waterfall개념)

-. 소프트웨어의 작은 세트 구현에서 시작하여 반복적으로 전체 시스템의 구현 및 배치될 준비가 될 때까지 진화버전을 향상

 

-. 반복적 개발 모델 종류

종류 설명
증분형 모델
(Incremental Model)		 요구분석서의 정의된 시스템의 기능별로 여러 개의 서브시스템으로 나누고 일부 기능만을 포함한 서브시스템을 릴리즈하고 다음에 새로운 기능을 추가해 가는 형태의 개발모델
진화형 모델
(Evolution Model)		 처음부터 시스템 전체 기능을 대상으로 하되 릴리즈할 때마다 더 완벽히 개발하는 형태의 모델

 

2. 반복적 개발 모델 유형

가. 증분형 모델

전통적인 폭포수 모델에 반복적 수행 개념을 결합하여 적용한 모델

여러 개발팀들이 전체 시스템을 기능별로 나누어서 개발하고자 할 때 유용

요구사항이 개발초기 정의되었을 경우 적용(무엇을 만들어야 되는지 확실하게 아는 경우)

 

-특징

-. 증분을 따로 개발 후 통합하는 방법으로 프로토타이핑 반복개념을 선형 순차 모델의 요소들에 결합시킴

-. 프로토타이핑과 같이 반복적이거나 각 점증이 갖는 제품 인도에 초점

-. 규모가 큰 개발 조직일 경우 자원을 각 증분 개발에 충분히 할당할 수 있어 각 증분의 병행 개발을 통해 개발 기간을 단축시킬 수 있음

-. 증분의 수가 많고 병행개발이 빈번히 이루어지면 관리가 어렵고 업무조율에 많은 노력이 필요

 

-. 증분형 모델의 단계

 

나. 진화형 모델

-. 시스템이 가지는 여러 구성요소의 핵심부분을 개발한 후 각 구성요소를 개선 발전시켜 나가는 방법

-. 시스템이 완성된 후에도 요구사항을 시스템에 적용

-. 발견된 요구를 수정하는 활동, 즉 개선을 위한 개발 노력을 반복적으로 시행

-. 요구사항이 개발 초기 정의되지 않았을 경우 적용(무엇을 만들어야 하는지 확실하게 모르는 경우)

 

-. 특징

특징 설명
Outline 필요 다음 단계로의 진화를 위해 전체 진화 과정에 대한 개요(Outline)가 필요
요구사항 수집 용이 프로토타이핑 모델의 변형으로 요구사항 수집을 진화 단계를 거쳐 완성
재사용성 향상 프로토타입 시스템은 재사용을 전제로 함
설계의 진화 각 단계의 증분 설계가 다음 설계에 반영됨

 

-. 진화형 모델의 단계

 

3. 증분형 모델과 진화형 모델 비교

구분 증분형 모델 진화형 모델
방식 시스템의 일부를 시스템화하여 구현/반복 후 결합하여 완성 핵심 요구사항을 프로토타입으로 개발 후 요구사항이나 개선사항을 추가하여 발전
특징 병행개발 가능
증분 수가 많을 경우 관리 어려움		 고객의 요구사항이  불명확할 때 유용
전체적인 릴리즈계획이 수립되어야 함
모태 폭포수 모델 프로토타이핑 모델
장점 대규모 조직에서 병행 개발을 통해 시간 단축 가능 고객요구사항 반영이  용이하고 요구사항이 불명확할 경우 유용
단점 과도한 증분 시 프로젝트의 위험 증가 추가 요구사항이 많아질 경우 일정이 지연될 수 있음

 

'메가노트 > 토픽과제(정리)' 카테고리의 다른 글

공공소프트웨어 사업영향평가제도(안혜진 선임님)  (0) 2022.10.08
Agile방법론(이상희 부장님)  (0) 2022.10.08
소프트웨어공학  (0) 2022.10.08
무선랜 보안(배준호)  (1) 2022.10.04
망분리(김도현)  (0) 2022.10.03

[Site Map]

 

소프트웨어공학 토픽 목차

  1. 반복적 개발모델(문경숙 수석님)
  2. 정보공학방법론(김정욱 대표님)
  3. Agile방법론(이상희 부장님)
  4. 요구사항관리(허남 대리님)
  5. 공공소프트웨어 사업영향평가제도(안혜진 선임님)
  6. 사업타당성 평가(이재용 부장님)
  7. 테스트 프로세스(김지웅 대리님)
  8. 블랙박스, 화이트박스 테스트(이강욱 선임님)
  9. 테스트 종류(임천규 수석님)
  10. 테스트 설계(홍진택 주무관님)
  11. 코드 커버리지(김도현 부장님)
  12. function point(배준호 대리님)
  13. 모듈화(황선환 이사님)
  14. 리팩토링(윤정우 국장님)
  15. 무중단 배포(유준수 사장님)

 

  1. ETA(김정옥 대표님)
  2. Project Scope Management(안혜진 선임님)
  3. PMO(이재용 부장님)
  4. 소프트웨어 아키텍처 평가(김지웅 대리님)
  5. 마이크로서비스아키텍처(홍진택 주무관님)
  6. UML 2.0(김도현 부장님)
  7. Class, Method 구현방법(이강욱 선임님)
  8. 객체지향설계원칙(임천규 수석님)
  9. ISO 25000(황선환 이사님)
  10. ISO 29119(윤정우 국장님)
  11. 소프트웨어 개발 프로젝트 품질비용(유준수 사장님)
  12. 소프트웨어 안전성 분석(문경숙 수석님)
  13. Formal Technical Review(배준호 대리님)
  14. CMMi(이상희 부장님)
  15. 정보시스템감리(허남 대리님)

 

 

 

'메가노트 > 토픽과제(정리)' 카테고리의 다른 글

Agile방법론(이상희 부장님)  (0) 2022.10.08
반복적 개발모델(문경숙 수석님)  (0) 2022.10.08
무선랜 보안(배준호)  (1) 2022.10.04
망분리(김도현)  (0) 2022.10.03
자율주행자동차보안(황선환)  (1) 2022.10.01

[정보보안 목차]

 

무선랜보안 기술 비교

구분 WEP WPA WPA2 WPA3
등장시기 1997년 2002년 10월 2004년 9월 2018년 6월
사용자 인증 동일한 SSID의 AP 및 모든 기기에서 동일한 PSK 사용 동일한 SSID의 단말에서 동일한 사전공유 키(PSK, Pre Shared Key)를 공유하는 '퍼스널 모드'와 IEEE 802.11x 인증 서버에서 EAP(Extensible Authentication Protocol)를 이용하여 단말마다 별도의 키를 배포하는 '엔터프라이즈 모드'가 있음
암호방식
(암호화 알고리즘)		 RC4 RC4-TKIP AES-CCMP AES-CCMP
키의 길이 40비트/104비트 104비트 128비트 128비트/192비트(엔터프라이즈)
현재 안정성 낮음 낮음 보통 높음
특징 - RC4 기반의 약한 암호화 능력
- 모든 AP가 인증기능 수행을 위해 암호키를 관리해야 하는 부담
- 하나의 AP가 한 개의 암호키 사용하여 암호키 노출시 해당 AP사용자 전체에 리스크
- AP에 대한 인증 미지원으로 허가되지않은 불법 AP에 접속할 가능성 높음

 - TKIP, AES 방식의 강화된 암호화
- AS(Authentication Server)의 통합된 인증서버통해 관리통해 암호키 관리 부담 경감

- TKIP : WEP를 소프트웨어적으로 확장하여, WEP 방식 하드웨어 교체 없이 구현 가능한, 무선 채널 보호용 공유 비밀키 동적 생성을 통한 무선 구간 암호화 알고리즘

- CCMP : AES가 제공하는 블록 암호 모드 중, CTR(Counter mode) 기반으로 CBC-MAC을 결합한 CCM(CTR 기반 암호화와 CBC-MAC기반 메세지 인증을 동시에 제공) 모드 기반 알고리즘

- RADIUS : 네트워크 통신에서 3A(Authentication, Authorization, Accounting)을 중앙에서 처리할 목적으로 사용하는 서버/클라이언트 프로토콜로 UDP를 사용한 인증서버

- EAP : 단순 캡슐화 개념의 포로토콜로, EAP 자체는 실제 인증 프로토콜이 아니며, 인증 방법을 전송하는 역할을 수행

 

무선랜 보안 취약점

구분 취약점 설명
관리적 무선 AP 장비에 대한 관리 미흡 파손, 도난 등이 발생하여도, 파악하지 못하는 경우 다수
사용자의 보안의식 부족 보안 정책과 보안 기능을 따르지 않는 사용자에 의해 허점이 발생 가능
전파 출력 관리 부족 전파 출력 조정을 하지 않아, 기관 외부로 무선랜 전파가 유출되어, 정보 노출 등의 취약점 발생 가능
물리적 무선 AP 외부 노출 비인가자에 의한 도난, 파손 및 리셋을 통한 설정 초기화 등의 문제
무선 단말기 분실 위험 및 정보 유출 분실 시, 저장 데이터 유출 및 내부 보안설정 유출 가능성
기술적 암호화 하지 않은 통신 데이터에 대한 도청 무선랜은 공기를 전송매체로 하여, Broadcast하는 특성으로 인한 도청/스니핑에 매우 취약
무선전파 전송 장비에 대한 DoS - 대량의 무선 패킷을 전송하여 무선랜 무력화
- 무선랜이 사용하는 주파수 대역에 방해전파 방사하여 통신에 악영향
비인증 AP(Rogue AP)를 통한 데이터 수집
(Evil-Twin)		 공격자가 불법 무선 AP를 설치하여, 무선랜 사용자들의 접속을 유도, 개인정보 등 데이터 수집

 

무선랜 보안 대책

구분 대책 설명
관리적  SSID 변경 및 Broadcast 금지 SSID 초기 설정값이 아닌, 새로운 값으로 변경, SSID를 Broadcast 하지 않고, 숨김 모드로 설정하여 노출 방지
Default PW 변경 초기 설정된 PW가 아닌, 추측하기 어려운 방식으로 주기적으로 변경, 무선 AP 관리자 모드 접속을 방지
MAC 주소 필터링 접속을 허용할 단말의 MAC 주소를 무선 AP에 사전 등록
물리적 물리적 접근 제한 도난 방지를 위한 보호케이스 설치, AP 리셋 버튼 차단 등
기술적 안전한 암호화 방식 권고 WPA2 규격의 AES-CCMP 방식 권고
안전한 인증 방식 권고 기업 환경 무선단말 인증은 WPA2로 RADIUS 서버를 통한 EAP 기반 인증 권고

- 자체적인 인증서버 구입이 어려울 경우 이동통신사에서 제공하는 인증서버를 통한 단말 인증 기능 고려

 

'메가노트 > 토픽과제(정리)' 카테고리의 다른 글

반복적 개발모델(문경숙 수석님)  (0) 2022.10.08
소프트웨어공학  (0) 2022.10.08
망분리(김도현)  (0) 2022.10.03
자율주행자동차보안(황선환)  (1) 2022.10.01
IPSec(이강욱)  (0) 2022.10.01

+ Recent posts

티스토리툴바