본문 바로가기

카테고리 없음

Domain 4 정보시스템 운영, 비즈니스 적응 유연성

하드웨어 도입 및 유지보수 계획

하드웨어 도입

하드웨어 구입을 위해서는 필요한 업무 사이즈를 정리하고, 이를 근거로 구입하게 될 H/W, S/W의 용량 산정하며 최종적으로 제안서 산정기준을 작성하여 벤더에게 배포 

 

하드웨어 도입/제안 평가 감사를 수행할 때 IS 감사인이 해야 할 일

- 도입 과정이 비즈니스 필요에 의해 시작되었는지, 그리고 이러한 필요에 대한 하드웨어 요구 사항이 명세서에 반영되었는지를 판단함 

 

- 여러 공급업체가 고려되었는지

 

하드웨어 유지보수 계획

- 일상적으로 유지보수가 필요한 각 IS H/W 자원을 위한 평판이 좋은 업체 정보

- 유지보수 일정과 유지보수 비용

 

유지보수 영역에 대한 감사 수행할 때 IS 감사인이 해야 할 일

- 공식적인 유지보수 계획 작성되고 관리자에 의해 승인되는지 확인

- 비용의 적절성 

(비용 과다원인: 절차 미준수, HW 노후화) 

 

하드웨어 모니터링 절차

 

1. 가용도 보고서 - 사용자 만족도 척도

- 컴퓨터 가동 시간, 사용자, 다른 프로세스 이용 가능 시간을 파악

- Downtime이라고 하는 정보시스템의 사용 불능상태의 존재 여부

- Down Time은 부적절한 하드웨어 환경, 지나친 운영 체제의 유지 관리, 예방적 유지 관리의 부족, 운영자 훈련 부족 등을 암시 

 

2. 하드웨어 오류 보고서

- CPU, 입출력, 전원, 기억장치의 장애 사항을 알려줌

- 시스템 엔지니어가 활용하는 보고서 

- 보고서는 중단되거나 반복적으로 발생하는 문제에 대하여 점검하여야 함

 

3. 이용도 보고서 - 자원 활용 척도 

- 처리 부하를 예측할 때,정보시스템 관리자가 사용

- 다중 사용자 전산 환경에서의 자원 이용도는 평균 85% ~ 95%

- 이용도가 95% 이상이면 IS 관리자는 여유공간을 확보하기 위해 사용자 및 응용 시스템 패턴을 검토하고 컴퓨터 하드웨어를 업그레이드해야 함 

- 85% 이하면 하드웨어가 처리 요구사항에 비해 과도한 것이 아닌지 따져볼 필요가 있음

 

4. 자산 / 장비 목록 관리 보고서 

 

매체 제거 프로그램

1. 매체 삭제 대상

- 종이류

- 자기 매체

- 광학 매체

 

2. 자기 매체 제거 기법

- 물리적 파괴(재사용X)

- 자성 제거(재사용X)

- 초기화(오버라이드)

- 삭제 

 

3. 파기 과정 검사 방법

- 사진 찍기

- 담당자 사인

- 비디오 녹화

 

인프라 운영과 자동화 

1. 운영자의 임무

- 비정상적인 작업 종료가 담당 부서에 의해 조사되고 문제가 해결된 후 컴퓨터 응용 재시동

- 백업 수행

- 정보처리 설비 관찰

- 문서화된 작업 일정의 준수 여부 모니터링 

- 문제 해결 및 인시던트 처리 수행

 

2. 소등 운영(무인 자동 운영)

- 주요 컴퓨터실 운영작업의 자동화를 의미하며, 작업 수행이 사람의 개입이 없는 환경 

- 자동화 운영의 이점

- IS 운영 비용 발생 예방 또는 감소 

- 연중무휴 운영 

- 시스템 오류 및 작업 중단의 감소 

 

3. 작업 스케줄링 소프트웨어 

- 수행되어야 할 작업과 특정 종속관계를 포함한 작업 실행 순서 목록을 작성 후 해당 작업을 수행하도록 한 배치 형태의 소프트웨어 

- 작업 정보가 한꺼번에 준비되므로 오류의 가능성 감소

- 운영자들에 대한 의존도 감소

- 작업의 의존 관계가 정의되므로 하나의 작업이 실패할 경우, 그 작업 결과에 의존하는 다른 후속작업들은 처리되지 않음 ->최종 결과 신뢰 불가 

 

4. 일정 검토 대상

- 규칙적 수행이 필요한 응용, 입력 마감시간, 데이터 준비 시간, 예상되는 처리 시간, 출력 마감 시간, 주요 성과 지시자들에 대한 수집 보고 및 분석 절차 

 

시스템 인터페이스

하나의 어플리케이션의 출력이 다른 어플리케이션의 입력으로 전달되는 과정에서 사람이 전혀 또는 극히 일부의 개입만 필요한 인터페이스

 

보안 이슈

- 시스템 인터페이스의 오동작에 기인한 부정확한 관리 보고서

- 중앙집중화된 추적 및 관리기법, 문서, 정부 규정에 따른 감사 증적 확보 필요

- 암호화, 강력한 접근 통제 및 인증, 수신자 검증 절차

- 자동화된 로그

 

추적 관리 프로그램

- 자동 암호화/복호화 및 데이터 파일에 대한 자동 전자 서명 기능

- 전송디는 데이터에 대한 분석, 추적 및 보고 기능

- 적절한 법적 준수 사항 보장

- 중단될 경우에 대비한 체크포인트나 재시작 기능

 

최종 사용자 컴퓨팅

최종 사용자가 자신의 정보 시스템을 설계/구현하는 것

 

장점: 응용 시스템의 빠른 구축 및 확산

 

단점

- 변경 관리 및 배포관리를 벗어난 다른 버전의 소프트웨어가 생산됨

- 보안성 결여

- 백업 미생성 

 

관련 위험

- 허가

- 인증

- 감사 로그

- 암호화

 

데이터 거버넌스 및 관리

사업 목적 달성을 위한 이해관계자 요구사항들이 평가됨

우선순위 식별 및 의사 결정 과정을 통해 데이터/정보 관리 방향이 정립

성과 모니터링

 

데이터 관리

- 참조 구조: 데이터 소유권, 적절한 보안 수준의 정의, 데이터 보유와 파기에 대한 요구사항 

 

정보 수명주기

- 계획 -> 설계 -> 구축/획득 -> 사용/운영 -> 모니터 -> 폐기 

 

감사인의 역할

- 조직의 사업 목적에 부합하도록 지원

- 표준을 사용하여 처리되는지 확인

- 정보자산들이 사업목적과 일관성있게 구성되었는지 확인

운영체제

소프트웨어 통제 기능 또는 파라미터

- 운영체제 내부에서 통제가 이루어지는 방법을 알 수 있는 가장 효과적인 방법은 소프트웨어의 통제 기능 및 파라미터를 검토하는 것

 

소프트웨어 무결성 이슈 

- 의도적인 실수와 우연한 변경으로부터 운영체제를 보호

- 특권 부여된 프로그램들이 사용자 프로그램에 의해 간섭받지 않도록 함

접근 통제 소프트웨어

컴퓨터의 자원에 대한 접근을 통제하고 접근 로그를 관리하여 시스템의 보안성 확보를 위한 전문 소ㅡ트웨어

 

설계 원칙

- 데이터에 대한 비인가적 접근 예방

- 시스템 기능 및 프로그램의 비인가된 사용 예방

- 데이터에 대한 비인가된 수정 및 변경 예방

- 비인가된 접근 시도 감지 또는 예방

 

접근 통제(사전 - 예방 / 사후 - 탐지/적발, 교정)

 

데이터 통신 소프트웨어 

유틸리티 프로그램

어플리케이션의 정상적인 처리와 시스템의 안정적인 운영을 위해 필요한 일상적인 작업을 수행하는 시스템 소프트웨어

 

유틸리티 통제 목적 및 의미

- 감독자 상태 특권을 직접 부여받은 사용자는 설치된 임의의 보안 메카니즘도 우회 통과할 수 있으므로해당 시스템과 자원을 실질적으로 소유한 것과 같음

- 정보시스템 감사인은 시스템 관리자가 제한받지 않고 시스템을 운영할 수 있는 범위를 확인할 필요가 있음. 어떤 경우에는 사용자 ID에 시스템 관리자의 슈퍼유저 계정과 동등한 권한이 부여될 수 도 있음 -> 범위 통제

- 대부분 유틸리티 기능은 보안 시스템 외부에서 실행될 수 있거나 활동의 감사 증적을 남기지 않고 사용할 수 있음 ->엄격 통제 

소프트웨어 라이센스 이슈 

1. 소프트웨어 라이센스 유형

오픈 소스: 소스코드 및 소프트웨어 배포 가능

프리웨어: 소프트웨어만 가능, 소스코드는 재배포 불가

쉐어웨어: 기능 제한, 사용 시기 제한 등이 있음 

 

2. 라이센스 지불 기준

- CPU

- 사용자 수

- 동시 사용자 단위

- 이용도

 

3. 소프트웨어 라이센스 위반 예방/탐지를 위한 IS 감사인 역할

- 사용되고 허가된 응용과 시스템 소프트웨어 검토

- 모든 소프트웨어의 계약서를 확보 및 검토 

- 설치된 소프트웨어 목록 확보하며, 필요한 경우 CPU 개수 및 CORE 수를 확인하여야 함

- 허가 받은 라이센스 수실제 설치된 소프트웨어 수의 적합성 확인

 

4. 소프트웨어 라이센스 위반을 예방하는 대책

- 소프트웨어에 자산 관리 프로세스 도입

- 소프트웨어에 대한 통제를 중앙 집중화하고 배포와 설치를 자동화 함 

- 모든 PC는 일정 수준 제한되어야 함 

- LAN에 통제 대상 소프트웨어에 연결되어 사용되는 동시 사용자 수를 조사하고 기록하는 계량 소프트웨어를 설치하고, 모든 PC가 이것을 통하여 응용 소프트웨어에 접근하도록 함 

- 적절한 라이센스와 관리자 승인 없이 소프트웨어를 설치하지 않겠다는 동의서에 서명하는 내용이 포함된 보안 정책을 강제함 

 

소스코드 관리 

- 소스코드에 대한 접근은 응용 프로그램 또는 공급자와의 계약조건에 따라 다름

- 소스코드 없을 경우 에스크로 계약을 활용하는 것은 중요함 

 

VCS 장점

- 접근통제

- 변경 내용 추적

- 공동 개발

- 이전 버전으로의 롤백 가능

- 분리 기능 

 

감사인의 역할

- 소스코드 접근 가능 사용자

- 변경 소스 코드 반영 가능 사용자

- 프로그램 목적 코드로의 조정 

- 변경 및 배포관리 조정 

- 소스 코드의 백업

용량 관리

- 장래 필요한 하드웨어의 미래 수요를 미리 예측하여 최적의 성능을 유지하기 위함

- 가용 자원들이 효과적이고 효율적으로 사용되어지도록 컴퓨터 자원들을 계획하고 감시하는 것

 

IT 서비스관리 프레임워크

 비즈니스 목적 달성을 위한 IT 서비스의 구현과 관리

 

정보시스템 관리 통제 기능

- 운영 자원의 효과적 및 효율적 사용을 최대한 보장하는 운영 계획 수립

- 적시에 보안 취약점이 식별되고 해결되는 것을 보증

- 침입 시도의 적발

- 정보 보안 문제의 적시 해결

- 운영 일정 변경의 검토 및 승인

- 네트워크, 시스템, 응용 프로그램의 변경에 대한 검토 및 승인

- 데이터의 신뢰성, 무결성, 그리고 가용성을 보증

- 작업 회계 보고서와 기타 감사 기록의 유지 관리

 

사고/문제점 관리

사고 처리 프로세스

- IT 서비스 중단에 따른 부정적 영향을 제거/감소시킴으로써 서비스의 연속성 증가

- 미해결된 문제들은 경영진이 정한 기준에 의거하여 이관이 이루어져야 함

 

문제 관리 프로세스

- 근본원인을 파악하기 위하여 주요 사고 또는 유사한 속성을 갖는 사고들의 조사와 심층분석을 통해서 현안을 해결하는 것을 목표로 함

 

오류 종류

- 프로그램 오류, 시스템 오류, 운영자 오류, 네트워크 오류, 통신 오류, 하드웨어 오류

지원/헬프 데스크

지원 기능

- 컴퓨터 문제의 원인 결정 및 적절한 교정 조치의 수행 

- 요청된 문제점 보고서 작성 및 문제점의 적시 해결 확인

- 특정 시스템과 관련된 질의에 응답 

- 원격 통신 처리에 대한 기술적 지언 제공

 

헬프데스크 기능

- 사용자에 대한 서비스-> 문제 해결

- 현안에 우선순위를 부여하고, 우선순위에 따라 문제점을 적절한 관리자에게 전달

- 해결되지 않은 문제에 대한 사후 관리

네트워크 관리 도구 및 문제점 관리 보고 검토

응답 시간 보고서

- 응답시간: 사용자 요청으로부터 최종 결과물이 제공되기까지 걸리는 시간

 

다운타임 보고서

- 통신 채널에 대한 가용성 추적에 사용

- 포함 내용: 전원/선로 장애, 트래픽 과부하, 운영자 실수 및 기타 비정상적인 조건

- 다운타임 증가 시 대응 방안

통신 채널 추가 및 대체

효율적인 선로로 전환

전원 추가 설비

접근 통제 향상

중장기적 모니터링

 

헬프 데스크 보고서

- 고객 상담 이력 및 문제 해결 기록

 

온라인 모니터: 데이터 전송의 정확성 확인

 

네트워크 모니터: 네트워크 노드 및 상태의 실시간 제공

 

네트워크 프로토콜 분석기: 네트워크 사용량을 포함한 네트워크 패킷 분석

 

변경 관리 프로세스

프로그램 변경 통제 절차

- 발생한 변경으로부터 유발될 수 있는 사고의 부정적 영향 최소화

 

프로그램 변경 통제 확인 사항

- 시스템 문서, 운영 문서, 프로그램 문서가 완전하고 최신이며, 확립된 표준과 일치하는지 여부

- 작업 준비, 작업 일정 계획, 운영에 대한 지침이 수립되어 있는지 여부

- 시스템 및 프로그램 시험 결과가 사용자와 프로젝트 관리자에 의해 검토 및 승인이되었는지 여부

- 필요한 경우 데이터 파일/시스템 변환의 정확성 및 완전성이 현업 부서 관리자에 의해 검토 및 승인이 되었는지 여부

- 사업운영에 부정적 영향을 미칠 위험들은 검토되어야 하며 복원 계획이 개발되어야 함

배포 관리

- 소프트웨어가 사용자에게 활용될 수 있도록 하는 과정

- 공식적인 변경을 포함하며, 문제 해결 번호와 서비스의 개선 번호로 구성되고 새로운 소프트웨어나 변경된 소프트웨어로 구성

품질 보증

- 통제에 따라 시스템의 변경 승인이 되고, 테스트되고, 운영 환경에 구현되는지 확인

- 프로그램 및 소스코드의 버전 등 감시

- 라이브러리언 소프트웨어로 프로그램 버전의 적절한 유지와 소스 코드에 대한 목적 코드의 무결성을 모니터링 

- 실행 소프트웨어 환경 내의 변경 사항을 수행하기 위한 안정적이고 통제된 환경 확립, 강화 및 유지 

- 컴퓨터 시스템을 적절히 테스트하기 위한 표준적이고, 일관성 있는, 또한 정확히 정의된 테스트 방법론의 정의, 수립 및 유지관리 

서비스 수준

SLA

- IT 조직과 고객과의 계약

- 제공되는 서비스를 구체적으로 명시함

- 서비스를 조율하고 측정하는데 사용

- SLA 사이클: SLR, SLA, SLM, SIP 지속적 개선을 위해

 

서비스 효율성 및 효과성 모니터링 도구

 

예외 보고서(비정상 종료 보고서)

- 부적절한 운영 지침과 운영 지원

- 부적절한 운영자 훈련 또는 성능 모니터링

- 부적절한 작업 순서

- 부적절한 시스템 구성

- 부적절한 용량 계획

 

시스템 또는 응용프로그램 로그

- 승인 받은 프로그램 또는 IT 직원으로 제한된 민감한 데이터로의 접근

- 승인된 프로그램만 실행

- 정확한 데이터 생산과 적절한 보호

 

운영자 문제점 보고서

- 운영자 조치의 적절성 및 추가 훈련 필요 여부 판단

 

운영자 작업 일정표

- 매우 중요한 업무 또는 부하 집중 기기에 중요

데이터베이스 통제

정규화: 관계형 데이터베이스에서 구조적/비구조적 질의를 만족시키기 위하여 필요한 테이블 정보의 양을 최소화하기 위하여 정규화 규칙을 사용한다는 것

 

데이터베이스 통제: 정확성, 완전성, 영속성을 보장하기 위한 통제 수립

 

체크 포인트: 시스템 장애 후 작업 흐름에서 자료 손실과 복구 노력을 최소화 할 수 있는 시점에서 재개를 위한 DB 체크포인트 선택

 

락킹 메커니즘

 

데이터베이스 재조직: 변경,삭제 횟수가 많아지면서 DB 파일 내부의 쓰레기 공간이 DB 파일에 많이 남게 되는데 이러한 쓰레기 공간을 제거하는 과정 

 

데이터 무결성

- 개체 무결성, 참조 무결성, 도메인 무결성

 

비즈니스 연속성 계획

BCP/DRP 목적

- 서비스의 중단상황에서도 조직이 핵심적인 서비스를 계속할 수 있게 하고, 재해로 인해 업무 활동이 중단된 경우에도 조직이 생존할 수 있는 것

- 이러한 상황에 대비하기 위한 계획 수립과 자원 투자 필요

 

핵심 프로세스 식별

- 비즈니스 목표를 달성하고 깅버의 지속적인 성장에 영향을 미치는 중요한 비즈니스 프로세스 식별

 

위험 평가

- 핵심 프로세스를 기반으로 위험평가 시작 

 

BCP/DRP의 정책

- 기업의 생존/자산보호에 대한 책임은 고위경영진에게 있음 

- 절차는 정책에 의함 

 

BCP 고려 사항

- 기업의 생존에 필요한 핵심 비즈니스 영역

- 핵심 영역을 지원하기 위한 인적/물적 자원

 

BCP/DRP를 위한 계획들

- 하나로 통합할 필요는 없지만 서로 일관성이 중요

 

지리적 고려사항

- 지리적으로 분산된 기업의 경우, 별도의 시나리오에 의해 수립 

 

정보시스템

정보시스템 BCP

-  대부분의 핵심 프로세스가 핵심 정보시스템 및 인프라의 가용성에 의존하고 있으므로 중요

- 기업의 전략과 일관되게 작성

 

정보시스템 BCP는 IT 서비스 연속성

- 데이터 센터는 지진대와 유독성 물질 지역을 피하고 이미 구축된 대체 처리시설에 네트워크 인프라는 루프나 메시와 같은 복원력있는 네트워크 구조 사용 

 

정보시스템 BCP 수립과 테스트

- 핵심 업무 프로세스, 애플리케이션 등 인프라 요소 간의 의존관계를 파악하는 것은 위험 평가 영역

- 위험 평가 대상에 대한 위협 및 취약성과 요소 간의 의존관계의 맵은 위험평가의 산출물

- 위협을 경감시키거나 취약점을 교정하는 위험 대응책의 선택이 필요

- 위험은 정성적, 정량적 방법으로 산출

 

BIA(비즈니스 영향 분석)

- 기업이 중단상황으로 야기되는 손실의 정도를 조사

- 기업으로 하여금 특정 시스템의 가능한 최대 중단 시간과 손실 데이터 양을 알 수 있게 해야 함

- 중단 상황 이후에 증가되는 손실을 측정하고 핵심 정보자산의 보호와 복구를 위해 사용되어야 하는 시설을 결정

 

재해 및 기타 중단 상태

재해

- 중요한 지식 자원의 사용불능으로 인한 중단 사태로서 비즈니스 운영에 불리한 영향을 줌

- 지진, 홍수, 태풍, 화재

- 테러, 해커의 공격, 바이러스, 인간의 실수로 인한 발생 가능성

 

중단

-핵심적인 서비스 중단은 재해 때문이 아닐 수 있음

- 시스템 고장, 불의의 파일 삭제, 서비스공격 등

 

BCP프로세스

프로세스 계획(비즈니스 연속성 정책, 프로젝트 범위) -> 위험 평가 및 분석 -> BIA -> 비즈니스 연속성 전략 개발 -> 전략 실행 -> 비즈니스 연속성 계획 개발 -> 비즈니스 연속성 인식 교육 -> 비즈니스 연속성 테스트 -> 모니터링, 유지보수, 갱신 

 

 

비즈니스 연속성 정책

경영진에 의해 승인된 문서

 

비즈니스 연속성 정책은

- 중단상황이 발생할 가능성을 감소시키기 위한 예방/적발 통제와

- 중단상황으로 인한 영향을 줄이기 위한 교정 통제

 

적발 통제 - 인프라 모니터링, 용량 관리, 사고 관리

예방 통제 - 예비 처리 장소, 위험 관리, 형상 관리

교정통제 - 백업 및 복구, BCP 또는 IT DRP, 공급 업체 계약 내의 특별 조항 

BIA 

핵심 프로세스와 이를 지원하는 IT 구성요소를 평가하고 시간대, 웃너순위, 자원 및 연관관계를 결정

고위 경영진의 전폭적인 지원과 IT 인력 및 최종사용자들의 폭넓은 참여가 필요

 

BIA 고려사항

어떤 것이 중요한 프로세스인가? - 평가(핵심/비 핵심 프로세스 구분)

- 중요성 척도

핵심 업무 프로세스와 연관된 주요 자원은 무엇인가?

- 가능성 있는 핵심 프로세스

중대하거나 수용할 수 없는 손실을 입기 전에 업무 프로세스가 재개 되어야 하는 정보 자원들의 핵심 복구 시간대란 무엇인가? 

 

BIA 결정을 위한 시스템 등급 분류

1. 핵심 

- 동일 수준의 성능으로 대체 되지 않는 한 수행될 수 없는 것

- 수작업 대체 불가능

- 중단에 대한 내성 낮음 = 0

- 중단으로 인한 피해 비용 높음

2. 중요

- 짧은 기간 동안만 수작업 수행 가능

- 핵심에 비해 중단에 대한 내성 높음

3. 민감

- 비교적 장기간 동안 수용 가능한 비용으로 수작업 수행

- 수작업을 위한 추가적 인력 필요 

4. 비핵심

- 중단 시 비용 일으키지 않고, 노력 없이 복구 가능

 

재해로 인해 서비스를 제공 못하는데 따르는 중단 비용(시간이 지나면 비용 커짐) 

BCP를 활성화 시키는 복구비용으로 복구가 진행되면서 줄어듬 

 

복구 시간을 길게 하면 복구 비용은 줄겠지만, 중단 비용은 증가

복구 시간을 짧게 하면 복구 비용은 늘겠지만, 중단 비용은 감소 

 

복구 계획이나 가능한 대안 식별

 

RPO(복구 목표 시점)

- 운영 중단이 발생할 경우 허용할 수 있는 데이터 손실량 근거

- 데이터를 복구하기 위해 수용할 수 있는 가장 빠른 시점

- 중단 사태 시 수용 가능한 데이터 손실량, 모든 데이터의 완벽 복구 불가능

 

RTO(복구 목표 시간)

- 운영 중단이 발생할 경우 허용할 수 있는 데이터 복구 시간에 근거

- 재해가 발생한 후 비즈니스 운영이 재개되기 위한 가장 빠른 시간

 

기타 이슈

BCP, DRP 수립과 검토

BIA를 근거로 하여 BCP, DRP수립과 검토

 

고려 사항

- 재해 이전의 준비, 대피 절차, 재해 선언 절차

- 재해가 선언되어야 하는 상황, 책임, 책임자, 복구 절차의 단계적 설명

1. 쉽게 작성 2. 문서화 3. 최신 

 

계획 수립과 관련된 기타 이슈 

- 재해 시나리오에 대응해야 하는 인력들은 가장 핵심적인 자원에 대한 책임을 맡은 인력

- 경영진 지원과 사용자의 참여가 핵심적인 BCP 수립의 성공 요소 

 

비즈니스 연속성 계획의 구성 요소

COOP(운영 연속성 계획)

- 최대 30일 동안 대체 사이트에서 조직의 핵심적이고 전략적인 기능을 유지하기 위한 절차 및 방법제공

- 본부레벨에서 작성 IT 초점 X

DRP(재난 복구 계획)

- 대체 사이트에서 복구를 진행하기 위한 상세한 절차 제공

- 대부분 IT에 초점, 오랜 기간 영향을 받은 주요 중단 상황으로 한정

BRP(비즈니스 복구 계획)

- 재난 발생 후 즉시 비즈니스 운영을 복구하기 위한 절차 제공

- 업무 프로세스를 지원하는데 기반이 되는 IT 포함 

 

기타 부분

- IT 비상계획 및 지원의 연속성

- 위기 시 통신 계획

- 사고 대응 계획 

- 수송 계획

- 거주자 비상 계획 1. 인명 최소화를 위한 절차 제공 2. 확산 방지 3. 재산의 손실 방지 

- 소개 및 비상 재배치 계획

- 사이버 사고 대응 계획 

 

BCP 사본의 보관

- 사본을 오프 사이트에 보관

- 전자 파일로 만들어 미러드 웹사이트에 보관

 

핵심 의사결정자 - IS 및 현업 인력

- 전화 번호 목록 

 

필요 물품의 백업

- 표준 복구 운영절차에 익숙하지 않은 직원도 쉽게 따라 할 수 있도록 상세하고 갱신된 사용설명서 포함

 

계획 테스트

한계와 목적

한계 : BCP 일부분만 진행

목적: 계획이 얼마나 효과적인지 평가하고, 어느 부분이 보완되어야 할 지 파악 

일정: 정상적인 운영을 중단하는 시간이 최소화 - 주말 

인원: 핵심 복구 팀원 모두가 참석, 충분한 시간

필요 내용

- 모든 중대한 사항은 반드시 테스트

 

테스트 형태

1. 체크리스트(문서테스트)

- 계획을 각 부서로 배포하여 검토

- 계왹에 중요 항목이 누락되지 않았는지 체크

 

2. 구조적/시운영 테스트 

- 각 업무 부서의 팀장들이 모여 계획을 상세히 검토

- 계획의 각 단계마다 각 부서가 취할 절차가 모두 언급되어 있는지 체크

- 비상 시 수행될 실제 작업이 모두 고려되는지 확인 

 

3. 모의 훈련

- 실제 재해 시 발생되는 데이터를 이용해서 테스트, 이 테스트는 대체 사이트가 선정되고 각 종 장비가 갖추어질 때까지만 실시

- 모의 재해에 대응하는 직원의 능력에 대한 테스트가 가능

 

4. 평행 테스트

- 중요한 시스템들을 대체 사이트에서 운영하며, 주사 이트에서 나온 결과물과 차이점 분석

 

5. 완전 중단 테스트

- 주 사이트에서 모든 운영을 정지시키고 백업 받아둔 데이터를 이용함

- 대체 사이트에서만 운영해 보는 테스트로서 비용이 많이 들고 위험하므로 상급자의 승인이 필요 

 

6. 준비도 테스트

- 전체 테스트의 일부만 테스트

- 지사별/부서별 완전 중단 테스트

- 비용대비 효과적인 방법, 계획을 점진적으로 향상 시킬 수 있는 수단 제공 

 

결과의 문서화

- 일기 형식

- 보험회사나 정부 제출 자료로 활용

 

결과 분석

- 계량적 측정

 

계획의 유지관리

- 중요한 변화/변경을 반영할 수 있도록 주기적 검토/갱신/테스트

- BCP를 SDLC 프로세스의 일부분으로 간주하는 것도 바람직

비즈니스 연속성에 대한 감사

- 비즈니스 연속성 전략과 비즈니스 목적과 연계성 이해/평가

- 비즈니스 우선순위와 통제가 반영된 BIA의 발견 사항 검토

- RPO, RTO 등의 기준과 계획의 적절성과 현재성 평가

- 테스트 결과 검토/ 효과성 검증

- 오프사이트 저장소 검토하고 적절성 확인

- 보안 요구사항을 만족하는 백업 미디어 전송 방법

- 수립된 유지관리가 주기적으로 개정되는지 확인

- BC 매뉴얼, 절차가 간단/쉬운 설명인지 확인/인터뷰

- 중요한 비즈니스 활동을 지원하는 정보시스템의 아웃소싱에는 BCP/DRP에 아웃소싱을 반드시 포함시켜야 함 

 

문서 검토

- 비즈니스 연속성 정책이나 전략의 최신 사본 입수

- 업데이트 절차로 평가된 문서가 시기 적절하게 업데이트되고 배포되는지 확인

 

계획에 의해 보호되는 애플리케이션 검토

- 서버 기반 및 워크스테이션 기반의 핵심 애플리케이션에 대한 식별, 우선순위 책정, 지원 계획이 적절한지 검토

 

비즈니스 연속성 팀 검토

- 각 복구/연속성/대응팀의 팀원 목록 입수

 

계획 테스트

- 테스트를 문서화하기 위한 절차 평가

 

과거 이전 테스트 결과 평가

- 과거의 테스트에서 수정 필요한 사항이 계획에 반영되었는지 확인

 

오프사이트 저장소 평가

- 중요한 미디어 문서의 존재, 동기화, 현재성 측면 평가

- 문서 검토 - 최신 버전

- 시설의 가용성

 

핵심 인력 면담

 

오프 사이트 시설의 보안 평가

- 물리적 보안과 환경 통제: 승인 받은 사람들의 시설 접근/ 이중 바닥, 습도 조절, UPS, 연기 탐지기, 소화기 시스템

 

대체 처리를 위한 계약 검토

 

보험의 보상 범위 검토 

 

이차사이트 구분 - 가용속도에 따라

mirrored

- 일차 사이트와 구성 동일

- 데이터 동기화 가능

- 많은 구축 비용

- 평상 시 철저한 검토

hot

- 신속한 가용성

- 호환성 테스트 가능

- 미러드 사이트에 비해 데이터 복구 필요

warm

- 필요 시 핫 사이트로 전환

- 저렴한 구축 비용

- 시스템 확보 필요

- 하드웨어 벤더의 영향력

cold

- 유지 비용의 최소화

- 데이터 백업만 준비

- 가용화 시간이 긺

- 시스템 확보 필요 

이차사이트 구분 - 소유 방식에 따라

자체 이중화

- 독자적으로 백업 사이트를 구축하여 운영

- 다양한 수준의 가용성 제공 속도를 확보함 

공동 투자

- 여러 업체가 공동으로 출자하여 백업 사이트를 구축함

- 공동 관리에 따르는 책임 소재 문제를 명확히 해야 함

상용 서비스

- 전문업체에 대체 처리 및 재해 복구를 위탁함

- 총 가입자 수, 일회 허용 사용자 수 및 사용 순서 등을 명확히 해야 함

(데이터 보안 등 확보 문제/ 신의성실 및 신뢰성 문제)

상호 협약

- 유사한 환경에 있는 조직들이 재해 시 상호 도움을 주기로 약정을 맺음 

(비용이 가장 저렴/장기적인 호환성이나 용량 제약/ 일과 시간 중 사용 제약)

이차사이트의 구축과 상용 대체 사이트 선택

구축 시 고려사항

- 일차 사이트와 동일한 자연 재해의 노출 아래에 있어서는 안됨

- 합리적 수준의 하드웨어 및 소프트웨어의 호환성 확보가 보장되어야 함

- 자원 가용성에 대한 보증을 얻기 위하여 작업 부하에 대한 감시를 수행해야 함

- 복구 대상 응용의 우선 순위에 대한 합의가 있어야 함

- 물리적 통제 및 보안 등에 대한 주기적 테스트가 필요

 

상용 대체 사이트 선택 시 고려 사항

재해의 범위 - 재해 상황에 대한 정의가 충분히 포괄적인가?

가용 속도 - 재해 이후 얼마나 일찍 사이트가 가용한가?

평균 가입자 - 사이트 당 사용자 수가 제한되어 있는가?

지역별 가입자 - 지역별 가입자 수가 제한되어 있는가?

선택권 - 동시 다발적 재해 시 사용 우선권 보유 업체는?

보험 - 백업 사이트 사원에 대한 보험 적용이 적절한가?

사용 기간 - 사용 가능 기간과 기술적 지원은 적정한가?

통신 - 통신 연결과 용량은 적정한가?

서비스 보증 - 벤더의 책임의 한계가 규정되었는가?

감사 - 논리/물리/환경적 보안에 대한 감사 권한이 있는가?

테스트 - 어떠한 테스트 권한이 있는가?

신뢰성 - 이차 사이트의 신뢰성을 보증하는가

처벌 조항 - 계약 취소 시 비용 처리는 어떠한가?

재해 대응 과정 단계

1. 비상 조치

- 인명 구조, 피해 확산 방지, 재해의 공지

- 일차 피해 평가 및 재해 선언

- 업무 연속성 계획 가동

2. 복구

- 대체 처리 사이트 준비, 테스트 및 업무 재개

- 복구 기간 동안의 비상 운영

3. 재구성

- 상세 피해 평가

- 일차 사이트 준비, 테스트 및 원상 회복

- 재해 종료 선언 

재해 대응 과정별 주요 활동 조직

1. 비상 조치 단계

- 비상 조치팀: 초기 대응(인명구조, 피해확산 방지), 재해 공지

- 평가팀: 원인 조사 -> 1차 피해 평가 -> 재해 선언

2. 복구 단계

- 비상 관리팀: 각 팀의 역할 조율

비상 운영팀: 2차 사이트 운영

네트워크 복구팀: WAN 복구 -> 광역 음성, 통신 복구

통신팀: 2차 사이트 내의 Local LAN 복구

코디네이터팀: 분산환경에서의 각 사이트 간의 역할 조정

3. 재구성 단계

- 구호팀: 상세 피해 평가 -> 1차 사이트로 이관 지휘 -> 재해 종료 선언

- 재배치팀: 1차 사이트로의 이관 업무 수행

- 회복팀: 1차 사이트 운영 

2차 사이트 업무 처리 용량 정의

Normal Level: 전체 업무를 처리하는 데 필요한 정상적 수준

SDO(Service Delivery Objective); 대체 사이트에서 확보하고자 하는 최소한의 처리 능력 수준

RML(Required Minimum Level): 핵심 업무를 수행하는 데 필요한 최소한의 처리 능력 수준

 

BCP/DRP에서의 IS 감사인의 역할

- 정부 정책의 비교: 계획의 적정성, 최신성 판단

- 테스트 참여/미참여 역할: 계획의 효고성 판단

- 오프사이트 스토리지 평가: 계획의 적정성, 최신성 판단

- IS 및 사용자 부서 평가: 직원들의 비상 대처 능력 평가

 

시간 구분

- RPO: 복구되어야 하는 거래 처리 시점. 데이터 유실량

- RTO: 업무 처리 능력을 복구하기 위한 목표 시점

- RP: 실제 업무 기능의 복구까지 걸린 시간

- MTD: 조직이 업무 처리 중단으로 인한 영향을 감내할 수 있는 최대 시간

- MTO: 이차 사이트에서 대체 처리를 할 수 있는 최대 시간 

 

- MTD=RTO=RP? 0 

(짧을 수록 내성이 짧고 빨리 복구해야함)

- RPO=0(업무 중단이 없고 데이터 동기 저장)

- RPO > 백업 주기 

전략적 백업 주기

- 백업 보존 기간: 법규 고려

- 백업 매체: 기술 노후화 고려

- 백업 순서: 하드웨어 ->소프트웨어 -> 데이터 -> 직원 

오프사이트 저장소

오프사이트 저장소 보관 항목

 

운영절차: 응용 실행 매뉴얼, 업무 흐름 통제 지시서, 운영 시스템 메뉴얼, 특수 절차

시스템 및 프로그램 문서

특수 절차: 예외 처리, 비상 시 처리 등과 같은 일반적이지 않은 절차나 지시

원시 입력 문서: 중복된 사본, 사진 복사, 마이크로 필름, 마이크로 피시

출력 문서: 감사, 과거 분석, 핵심적인 일의 성능 등

기타: 최신 버전의 BCP 사본

백업 방식과 백업 량

플 백업: 디스크 상의 모든 파일들에 대한 백업

- 백업 매체 보관이 용이

- 백업 수행 시간이 긺

차등 백업: 최근 전체 백업 이후 변동된 파일만 백업

- 소요 시간은 증분 배겁 시간과 전체 백업 시간 사이

- 증분 백업에 비해 백업에 소요되는 시간이 긺

증분 백업: 최근 모든 백업 이후 변동된 파일만 백업

- 저장 매체 활용이 효율적이며, 백업 시간도 절감됨

- 복구 시 많은 저장 매체가 필요함 

RAID

- 물리적으로 독립된 디스크에 데이터를 중복해서 저장하여 시스템 성능, 데이터 복구 및 무결성 보증 등에 사용됨

RAID

1) Striping

- 데이터 요소를 분리하여, 여러 디스크 드라이버에 분산 저장함

- 데이터 읽기 및 쓰기 속도가 빨라져 성능이 향상됨

2) Mirroring

- 동일 데이터를 동시에 여러 디스크 드라이버에 동시 저장함

- 성능 향상은 없으며 데이터 가용성이 제고됨

3) Parity

- 데이터가 누락되거나 덮어 쓰였는지의 여부를 검증함

- 데이터 복구를 지원할 수도 있음

RAID Levels

- Level 0: Striping. 입출력 속도의 향상

- Level 1: Mirroring. Fault-Tolerance 제공. 많은 저장 공간 필요

- Level 2: Bit-Level Striping 자주 사용안함

- Level 3: Byte-Level String + Dedicated Parity

- Level 4: Block-Level String + Dedicated Parity

- Level 5: Block-Level String + Distributed Parity

 

Application 복구 - 서버 이중화

장애 대응 전략

1) Fail-Safe or Fail-Secure 전략

- 장애 안전 또는 장애 보호

- 장애로 인한 시스템 손상을 예방하기 위하여, 장애 시 모든 기능이 정지됨

2) Fail-Soft or Fail-Resilient 전략

- 장애 완화 또는 장애 흡수

- 장애 시 비핵심 기능들을 정지하지만 핵심 기능은 지속적으로 작동

3) Fail-Over(Active-passive)

- 장애 극복

- 중복 서버는 Active-Standby 상태로서, 중단 시 이차 서버가 기능을 제공함

4) Fail-Tolerant or Fault Tolerant

- 장애 감내 또는 고장 감내

- 중복 서버는 Active-Active 상태로서, 평상시에도 일차 서버와 이차 서버가 동시에 기능을 제공

- 하드웨어 중복을 통해 장애 시에도 기능이 지속됨

- 어떠한 중단상태도 발생하지 않음

- 로드 밸런싱 기능이 있음

 

 

반응형