본 연재는 "네트워크 운영 관리의 기초」에 대해 소개하고 있습니다. 독자 여러분은 "네트워크 운영 관리"라고 묻자, 아마 "아, 저런 일 일까?」라고 그 실제 작업 내용은 웬지 모르게 이해하고 있는지라고 생각합니다. 이 연재는 그 "왠지"를 좀 더 체계적 세워 조립하는 것을 목적으로합니다. 제 3 회는 네트워크 운영 관리에서 수행해야 나날의 업무 내용을 소개하고 있습니다.
운용 관리 업무는 "감시"로 시작
네트워크 운영 관리에서 수행해야 나날의 업무는 무엇보다도 「감시」있어 나무입니다.제 1 회 기사에서도 소개했듯이 원래 운용 관리 업무는 "날마다 물건을 차질없이 잘 활용하는 것"이므로, 그것이 잘되어 있는지 아닌지 감시가 필요합니다.
네트워크를 모니터링 한 결과에 따라 다음에 다음과 같은 세 가지 업무를 수행 할 수 있습니다.
그림 1 관리 업무와 모니터링의 상호 관계 모니터링은 각 업무 목적에 따라 각각의 방법으로 실시 할 필요가 있기 때문에, 실제 모니터링 방법은 각 업무의 일환으로 소개합니다.
또한 각 관리 업무는 그림 1과 같이 일부가 중복 된 것입니다. 예를 들어, "네트워크 속도"라는 사건은 기본적으로 성능 관리 업무의 범위 사건이지만, 생각하기에 따라서는 장애 관리 업무에서 다루어 져야 할지도 모릅니다.
각 관리 업무별로 수행 할 내용을 설명하고 갑시다.
장애 관리 업무는 "조기 발견」 「조기 해결" "재발 방지"
장애 관리 업무의 주요 목적은 다음 세 가지입니다.
- 장애의 조기 발견
- 장애의 조기 해결
- 장애의 재발 방지
장애의 조기 발견
네트워크 장애는 네트워크를 이용하고있는 사용자가 처음으로 깨달으 것입니다. 그래서 일반적으로 사용자의 장애 연락이 트리거되고 " 발견 "이되는 것입니다 만, 그것과는 별도로 관리의 측면에서도 문제를 조기에 발견하기위한 장치를 마련하고 싶은 것입니다 .
장애 발견 방법은 발견해야 할 장애의 유형에 따라 다릅니다. 발견해야 할 장애는 사전에 정책 으로 정한 것이 이에 해당됩니다 (정책 개발 내용은 제 2 회 「네트워크 건전화 정책을 만들자 "를 참조하십시오).
예를 들어, 네트워크를 구성하고있는 기기가 단순히 시작하는지 여부를 확인하기 위해 자주 사용되는 것이 ping 명령입니다. ping을 각 기기에 정기적으로 칠 (전송)하여 해당 장비가 "살아있는"돌고래 "죽은"돌고래 판별이 붙습니다.
좀 더 세부적으로 각 장비의 상태를 파악하기 위해 SNMP 를 사용합니다. 단순히 장애만을 감지하는 경우, 기기의 상태 통보 (TRAP)을 집어 방법을 제공하고 그 결과를 어떻게 든 경고 메시지로 출력하고 관리자에게 알리도록합니다. 장애 발생시 갑자기 아는 것이 아니라 사전에 " 예측 "할 수 있도록하려면 정기적으로 각 기기에 대해 SNMP를 통한 문의 (GET REQUEST)를하고 거기에서 얻은 정보에 의해 예측합니다.
장애의 조기 발견에서 고려해야 할 것은 무엇을 가지고 " 장애 "로 간주 하는가하는 점입니다. 전체 네트워크를 사용할 수없는 경우라면, 그것은 물론 장애이지만, 그에 대해 「우선 연결 수는 있지만 왠지 느리다 "등의 케이스는 귀찮습니다. 어디까지가 정상이고 어디부터가 오류인지를 미리 정책은 명확한 수치로 확인할 수 있도록 정해 둡니다.
장애의 조기 해결
오류가 발견되면 이번에는 그것을 얼마나 빨리 안정적으로 해결하는 것이 중요 포인트입니다. 그 때 제일 중요한 것은 " 당황하지 수 "입니다. 그렇다고는하지만, 막상 일이 일어나고 보면, 사용자는 "빨리 어떻게 든해야한다"고せつか하고 당황해서 대응 한 결과, 불필요한 문제를 복잡하게 해 버리거나 .......
그런 사태가되지 않기 위해서는 미리 대응 절차를 결정하는 것이 필요합니다. 기본적으로 발생이 예상되는 장애에 대해 발생하는 경우를 상정하고 절차를 정해두고 있습니다.예를 들어 다음과 같은 흐름도에 따라 절차 생각합니다.
그림 2 실패시 대응 절차 흐름도 예를 들어, 그림 2의 "장애에 대한 대응"부분에서 기기 고장이면 정상적인 것으로 교체 등 장애 유형에 따라 어느 정도 단계를 정해 둘 수 있습니다. 고려해야 할 것은, 장애 격리 및 대응에서 통신 사업자 및 제조업체와의 연락 체제를 어떻게 하는가하는 점입니다.장애 발생시 연락처로 통신 사업자 및 제조업체를 포함 해 두었다가 문제 구별에서 맡기는하거나 어느 정도의 분리를 실시한 데다가 대응 만 맡길 것인가를 명확히해야합니다.
또한 문제 구별 자체에도 고려가 필요합니다. 전술 한 바와 같이 장애는 먼저 사용자에 의해 발견됩니다. 거기에서 " 해결 "이 시작 것입니다 만, 아무래도 사용자가 오류 발견보고는 체계적인 것이 아니라 필요한 정보가 갖추어져 있지 않습니다. "네트워크가 연결되지 않는 것이지만"라고 한 것만으로는 문제 구별 및 분석 할 수 없습니다. 사용자에게서 필요한 정보를 이끌어 내기위한 방안이 필요합니다. 구체적으로는, 질문 사항을 체크리스트 에 접어 사용자의 장애 연락이 오면이 체크리스트에 따라 질문을하고 필요한 정보를 수집합니다.
장애의 재발 방지
장애의 재발 방지는 먼저 이미 발생 해 버려, 그 대응을 보이는 장애에 대해 재발을 방지하기위한 대책을 세우기 시작합니다. 이번 대응이 일시적인 것이라면 물론, 그렇지 않은 경우에도 다른 곳에서 비슷한 오류가 발생하는지 여부의 검토를 포함하여 시스템의 전반적인 재발 방지책을 검토합니다.
아직 발생하지 않은 오류도 미연에 방지하려면 어떻게하면 좋은가를 생각해야합니다.구체적으로는 다음과 같은 작업을 수행 할 것입니다.
- 각 장비 및 소프트웨어 구성 정보 관리
- 변경 내용 추적
- 장비 및 환경의 정기적 인 조사
- 충분한 자원 배정
- 장비의 추가 및 구성 변경 이전에 작동 확인
- 중요한 네트워크 장비 및 회선의 이중화
- 네트워크 관리 시스템의 도입
성능 관리 업무는 "성능 유지」 「확장 지원"
성능 관리 업무의 주요 목적은 두 가지입니다.
네트워크 성능 유지
성능 관리 업무의 주요 목적은 네트워크 성능의 유지에 있습니다. 즉 네트워크의 성능을 일정 수준으로 유지하는 것이 목적입니다. 구체적으로는 다양한 성능 관리 항목에 대해 미리 기준치를 정하고두고 그 기준치를 초과하거나 밑돌 지 않도록 그 대응을 할 수 있습니다. 성능 관리 항목은 다음 표에 표시된 것처럼 같은 항목이 있습니다.
| 분류 | 관리 항목 | 개요 |
|---|
| 네트워크 자체에 대한 항목 | 응답 시간 | 데이터 단말의 응답 시간 (초) |
|---|
| 처리량 | 단위 시간당의 정보 전달량 |
| 트래픽 | 루트마다 구간 별 트래픽 |
| 트래픽 평가 | 시간 분포, 연도 분포, 지리적 분포 |
| 회선 사용률 | 통신 회선 사용률 (%) |
| bit 오류율 | 전송 도중 오류 비율 (%) |
| 루트 바쁜 계산 | 웹 의복 횟수 |
| 가상 경로 수 | 패킷 교환망에서 말하는 VC의 수 |
| 장비 관련 항목 | CPU 사용률 | 네트워크 장비의 CPU 사용률 (%) |
|---|
| 버퍼 사용률 | 네트워크 장비 내부의 버퍼 사용률 (%) |
| 큐 체인 버퍼 수 | 네트워크 장비 내부의 큐 체인 데이터의 수 |
| 패킷 처리 | 단위 시간당 패킷 처리 수 (PPS) |
| 교환 처리 | 단위 시간당 교환 처리 수 (CPS) |
| 표 1 네트워크의 직접적인 성능 항목 |
위의 표에서 각 항목은 어느 정도 직접적 으로 성능을 나타내는 것이지만,이 외에도 통계로 간접적 으로 성능을 나타내는 항목도 있습니다.
| 항목 | 통계 수치 |
|---|
| 송수 byte 수 | 일정 시간에 흐른 byte 수 |
|---|
| 송수신 프레임 수 | 일정 시간에 흐름 프레임 수 |
|---|
| 송수신 프레임 종류 | 상기 프레임의 종류 |
|---|
| 송수신 패킷 수 | 일정 시간에 흐름 패킷 수 |
|---|
| 송수신 패킷 종류 | 상기 패킷의 종류 |
|---|
| 오류 카운트 | CRC 오류 전송 언더런 등의 오류 |
|---|
| 표 2 네트워크의 간접적 인 성능 항목 |
대응 방법으로 우선 생각할 수있는 것이 네트워크 트래픽을 모니터링하는 툴을 이용하여, 현재 네트워크에 어떤 트래픽이 있는지를 확인하는 것입니다. 트래픽의 비정상적인 증가에 의해 성능이 저하되어있는 경우, 도구를 확인하여 신속하게 해명 할 수 있습니다.
그 때 네트워크를 흐르고있는 트래픽 중 일반적으로있을 수있는 것과 그렇지 않은 것을 판별하기위한 기초적인 정보가 필요합니다. 각 서버 나 클라이언트에서 언제 어떤 트래픽이 발생 하는지를 파악하고 있어야합니다.
게다가 일반적으로있을 수없는 트래픽과 그 발생원을 규명 왜 그런 상황이 있었는지 원인을 조사합니다.
네트워크의 확장 지원
네트워크를 둘러싼 환경은 항상 변화하고 있습니다. 변화 중에서도 특히 큰 것은 새로운 직원이 입사 한 등의 사용자 증가가 이에 해당합니다. 사용자의 증가만큼 네트워크 트래픽도 증가 해 지금까지의 네트워크 성능을 유지하는 것이 곤란하게되는 경우가있는 것입니다.
미리 알려진 이벤트라면 그에 대비하는 것도 가능합니다. 조직의 연락 체제를 확립하고 조직 내에서 예정되어있는 이벤트 정보를 가져옵니다. 그것과는 별도로 환경의 변화에 따른 네트워크의 거동을 예측하기위한 기초 데이터를 수집해야합니다. 예를 들어, 현재의 사용자 수 당 트래픽 량이나 각 기기 당 사용량 등의 정보입니다.
그림 3 네트워크의 상태를 예측하기위한 흐름도 사용자 수의 증가뿐만 아니라 새로운 시스템의 가동 등에 따라 트래픽이 증가합니다.새로운 시스템이 언제 어떻게 트래픽을 얼마나 양만 내는지 정보를 수집합니다.
보안 관리 업무는 "클라이언트" "서버" "네트워크"를 유지
보안 관리 업무의 주요 목적은 다음 세 가지입니다.
- 클라이언트 보안 유지
- 서버 보안 유지
- 네트워크 보안 유지
모두 미리 "(보안) 정책"으로 조직 단위로 결정하고 문서화 된 것 따라 수행하는 업무입니다.
공통적 인 업무 작업
클라이언트, 서버 및 네트워크의 각각에 대한 보안 관리 업무에 공통적 인 작업이 있습니다.
보안 정보의 수집 / 배포
보안을 유지하는데있어서에서는 어떤 위협 (위험) 가 있는지, 또한 그것을 통해 어떤취약점 이 있는지를 항상 확인해야합니다. 그리고 위협과 취약점은 날마다 새로운 것이 등장 · 발견되고 있습니다. 항상 최신의 정보를 입수하고이를 바탕으로 대응이 필요합니다.
또한 수집 된 보안 정보 보안 담당자 만 알고 있으면 좋은 것이 없습니다. 보안 담당자뿐만 아니라 일반 사용자도 말려 들게 한 것이어야합니다. 입수 한 정보 중 일반 유저에게도 공개해야 할 정보는 바로 그것을 어떤 방법으로 공개하고 있습니다.
공격의 발견 · 대응 · 기록 · 개선
보안적인 사건 (사건) 가 발생했을 경우, 즉 어떤 공격이 발생한 것으로 판명 될 경우 그에 대응해야합니다. 대응은 작업 흐름에 따라 수행해야하지만, 기본적으로는 전술 한 「재해 작업 흐름 "과 동일합니다.
클라이언트 보안 유지
클라이언트 컴퓨터 및 그것을 이용하는 사용자의 보안을 유지합니다.
사용자의 보안 의식의 향상
먼저 수행 할 업무는 사용자의 보안 의식의 향상입니다. 보안 유지는 보안 담당자뿐만 아니라 사용자 개개인에 "보안 중요"라는 의식이 없으면 실현 될 수 없습니다. 사용자에게 요구하는 것은 어디 까지나 의식의 문제이고 기술적 인 지식을 요구하는 것은 아닙니다.
계몽적인 강습회를 실시하고, 메일 매거진 등으로 정기적으로 보안 정보를 공개하고, 날마다 사용자의 보안 의식 향상에 노력합니다.
업무 이외의 Web 참조 금지
이것도 사용자 의식에 의한 것이 크지 만, 업무 요건 이외의 Web 참조를 금지하는 것이 필요합니다. 그렇지 않고 사용자가 마음대로 네트워크를 사용하는 경우 예를 들어, 네트워크 대역폭을 낭비하게되고, 또한 바이러스 감염 및 기밀 정보 유출로 이어집니다.프록시가 있으면, URL 및 키워드 등으로 필터링하여 액세스를 차단하고 그 때 기록하고 나중에 사용자 나 그 상사 등에 제시하여 억제 효과를 노립니다.
패치
OS 나 응용 프로그램의 취약성을 악용 위협이 매일 등장하고 있습니다. 보안 정보 수집을 게을리하지 않고, 그 결과에 따라 필요한 패치, 적용합니다.
단,이 작업을 개별 사용자에게 실시하게하는 것인지 아닌지는 점은 고려해야합니다. 사용자의 IT 리테라시 기술에 따라 다르지만 사용자에게 작업을 할당하면 균일 한 적용은 바랄 않고, 결과적으로 전체 네트워크의 보안 강도를 저하 시키게도됩니다. 강제적이고 총괄적인 어떤 방법을 사용할 수 있어야합니다.
안티 바이러스 (정의 파일)
패치와 함께 중요하게되는 것이 바이러스 백신 소프트웨어의 사용입니다. 특히 바이러스 정의 파일의 업데이트가 중요합니다. 모처럼 안티 바이러스 소프트웨어가 설치되어 있어도 정의 파일의 업데이트가 이루어지고 있지 않으면 대응할 수없는 바이러스의 수가 그만큼 많아지고, 감염의 위험성도 높아집니다.
이에 대해도 개별 사용자에 맡기면 제대로 작동하지 않을 수도 있기 때문에 어떤 강제적 인 방법이 필요합니다.
기술 지원
사용자의 요청과 인시던트 연락 창구가됩니다. 보안 대책이 사용자를 끌어 들인 것이된다 이상이 같은 창구가 필요합니다.
불법 클라이언트 확인
바이러스의 침입 경로 중 하나로 사용자 소유의 컴퓨터, 특히 노트북의 기업 네트워크에 무단 연결합니다. 또한 무단 사용자가 기업 네트워크에 무단 접속 한 후, 서버 등에 침입 할 가능성도 있습니다.
이러한 위협을 피하는 의미에서 네트워크에 연결된 컴퓨터의 드러내 검사를 정기적으로 실시하고, 스위치 등의 네트워크 장비에 의한 무단 접속 방지 조치를 실시해야합니다.
계정 관리 (암호 사용 기간)
침입 한 방법으로 사용자 사칭 있습니다. 부정 사용자는 우선 일반 사용자 계정과 암호 정보를 검색하려고 시도합니다. 특히 암호는 자주 변경하는 것이 대항 조치됩니다. 미리 사용 기한을 마련해 그에 따라 사용자에게 변경을 재촉합니다.
서버 보안 유지
서버 컴퓨터의 보안을 유지합니다. 각 서버가 어떤 용도로 어떻게 이용되고 있는지, 각 서버에서 어떤 서비스 (데몬)이 움직이고 있는지를 파악해야합니다.
패치
클라이언트 컴퓨터와 마찬가지로 OS 나 응용 프로그램의 보안 정보 수집을 게을리하지 않고, 그 결과에 따라 필요한 패치, 적용합니다.
안티 바이러스 (정의 파일)
이쪽도 클라이언트 컴퓨터와 같이, 특히 바이러스 정의 파일의 업데이트가 중요합니다.
백업
어떻게 보안 방어를 굳혀 놓은 경우에도, 언젠가는 찢어 버릴 것이라고 전제에 서서 그 사태에 대비하는 것이 필요합니다. 구체적으로는 시스템이나 데이터가 파괴되어 버려도 좋다 있도록 백업을 준비해 둡니다. 간단한 데이터 백업뿐만 아니라 장비 및 회선까지 포함한 전체 시스템의 백업 (듀얼 시스템)을 실시해두면 복구까지의 지연 시간을 줄일 수 있습니다.
로그보기
서버는 특히 공격 대상이되기 십상입니다. 서버에 대한 공격이 행해졌거나 행해지되고 있는지를 파악하기 위해 서버에서 다양한 이벤트를 기록하고 그것을 정기적으로 확인합니다.
로그는 서버에서 실행중인 OS의 로그 및 OS에서 실행하는 각종 서비스 (데몬)의 로그가 있습니다. OS 로그에서는 시스템 부팅 사용자 로그인 / 로그온 기록, 명령이나 프로그램 실행 기록 등을 확인합니다. 서비스 (데몬)의 로그는 서비스 (데몬) 자체의 기동 기록, 구성 (설정)의 기록 등에주의합니다.
데이터 변조 / 파괴보기
서버는 일반적으로 사용자가 공유하는 데이터 등이 있습니다. 이 데이터가 훼손되거나 파괴되거나하면 업무가 정지하고 손해가 발생합니다.
서버에서 데이터를 변조 또는 파괴되지 않음을 정기적으로 확인해야합니다. 이렇게하려면 데이터 파일의 타임 스탬프와 크기를 확인하고 체크섬 변조 검사 등을 실시합니다.
네트워크 보안 유지
전체 네트워크의 보안을 유지하고 있습니다. 내부 네트워크와 외부 네트워크를 연결하는 경로에는 어떤 것이 있는지를 파악해야합니다.
IDS (Intrusion Detection System) 로그보기
네트워크 형 IDS 및 호스트 IDS를 각각 필요한 위치에 설정해야합니다. 그 결과 로그를 정기적으로 확인하고 침입 여부를 확인합니다.
방화벽 로그보기
방화벽 작업 로그를 정기적으로 확인합니다. 특히 통과를 차단하는 패킷에주의합니다.
네트워크 장비 (라우터 등) 로그보기
라우터 등의 네트워크 장비가 가지고있는 로깅 기능을 사용하여 액세스 제어의 기록과 환경 (설정)의 기록 및 장비의 재시작 기록 등을 정기적으로 확인합니다.
이번에는 네트워크 모니터링에 따라 발생하는 관리 업무의 구체적인 내용을 설명했습니다.
Open SSH 형식
Cisco 라우터 - SSH 액세스
seburan
스톰 제어
그림 1 원격 모니터링의 장점으로는 모니터링 대상 시스템에 영향을주지 않고 감시 할 수있는 것을들 수있다. 단점은 취득 할 수있는 모니터링 정보에 한계가있는 것이다
그림 2 에이전트 모니터링에서는 추가 모니터링 데이터를 검색 할 수있는 장점이있다 (다른 시스템 운용이 가능하게되는 에이전트 수있다). 반면 모니터링 대상 시스템에 영향을 미치는 단점이있다
