프로젝트 및 업무 일정 관리 시스템 리뉴얼

Posted by taeho Tae-Ho
2015.01.11 17:41 나의 일

예전에 만들어 사용하던 SW 기술지원팀의 프로젝트 및 일정관리 시스템은 단지 "고객사"-"프로젝트" 단위로만 일정 등록이 가능했다. 하지만 필자가 프리세일즈를 수행하는 컨설팅팀으로 자리를 옮기면서 업무의 종류가 다양해 졌다. 


고객사 관련 업무가 아닌 제품소개자료의 작성

기술채널사의 엔지니어들을 대상으로 하는 정기교육의 강의 

또는 외부 강의...

홈페이지에 업로드 될 기술자료의 작성...

일주일에 한두 번씩 나가는 제품설명회...


등등 고객사와 프로젝트의 분류 만으로는 감당이 안되는 다양한 업무들을 함께 수행하게 되었다.


그래서... 기존의 프로젝트 및 일정관리 시스템을 리뉴얼 하면서 업무의 분류를 조금 더 세분화하여


공통업무,

세일즈업무,

컨설팅업무,

고객사,

연구/개발업무


등으로 세분화하여 업무를 등록하고 일정을 관리할 수 있도록 리뉴얼 하였다. 이 시스템은 CentOS 6.4, Apache 2, Mysql 5, PHP 5 로 구축된 서버에 그누보드 5.0을 설치한 뒤 PHP 코드를 구현하여 구축하였다. 사실 전문 개발자와 코웍할 수 있다면 판매할 수 있는 개발/영업/구현을 아우르는 CMMI 시스템을 만들어 비지니스를 해보고 싶은 생각도 있다.


1. 팀관리 및 팀원관리


어떤 시스템을 관리하든 멤버와 그룹의 관리는 필요하다. 예전의 일정관리 및 프로젝트 관리 시스템은 제로보드4의 회원시스템을 그대로 사용하였다. 제로보드는 회원관리에 그룹의 개념이 들어가 있어 그룹을 그대로 팀으로 구분하면 되었다. 하지만 이번엔 그누보드를 사용하기로 했다. 왜냐하면 그누보드에는 모든 테이블에 확장필드라는 것이 10개씩이나 존재해서 훨씬 확장성이 높기 때문이다. 회원의 정보에 확장필드를 사용하여 팀과 팀ID를 기록하여 사용하기로 했다.


당연히 그누보드의 회원에 대해 팀을 할당하고 변경할 수 있도록 페이지를 만들었다.



2. 업무 분류 관리 (카테고리, 대분류(고객사), 단위업무(프로젝트) 관리)


이 부분의 개념이 제일 까다롭다. 모든 업무 수행은 업무분류(대업무)와 단위업무(소업무)로 구분하였다. 공통업무의 "휴가"를 예로 들면 휴가는 전 사원의 공통업무다. 그리고 휴가에는 "연차휴가", "월차휴가", "병가", "공가" 등 다양한 형태의 휴가가 있다. 따라서 "휴가"라는 대업무에 4개의 단위업무가 포함된다. 


기술지원업무의 경우에는 업무분류(대업무)를 "고객사"로 잡았다. 그리고 단위업무는 "프로젝트(사업)"으로 정했다.

모든 업무를 2단계로 구분하여 등록함으로써 DB에서 업무분류 테이블과 단위업무 테이블 2개로 모든 업무를 관리하도록 설계했다. 다만 DB에는 업지만 업무분류(대분류)를 4개의 카테고리로 구분하여 대분류에 카테고리가 지정되도록 했다. 결국 3단계의 업무 구성이 이루어지도록 설계하였다.


즉 "공통업무", "고객사지원업무", "컨설팅업무", "연구/개발업무"의 4개의 카테고리 하위에 업무분류(대분류)와 단위업무(소분류)가 등록된다.


이렇게 등록된 단위 업무/프로젝트는 이슈 관리는 물론 산출물 관리에서도 주요 키로 사용될 수 있다.(보러가기)


3. 일정 수행의 유형 관리


일정관리 및 프로젝트 관리를 수행하다 보면 단순히 업무의 종류 또는 프로젝트 단위로만 분석하게 되는 것은 아니다. 일반업무나, 프로젝트, 개발업무는 모두 각 업무 특성에 적합한 업무의 유형 혹은 업무의 수행 단계가 있다.


예를 들어 내가 몸담고 있는 서버보안 프로젝트의 경우 "현황분석","설치", "정책협의", "정책적용", "감사로그분석", "정책검토/수정" 등의 단계별 업무가 있다. 따라서 이러한 단계를 일정 등록 시 "일정 유형"으로 지정하게 되면 사후 프로젝트별로 어느 단계에서 얼마나 시간을 소비했는지를 산출할 수 있다.


다만 업무분류 즉, 일반업무인지, 고객사 지원업무인지, 컨설팅업무인지, 연구/개발업무인지에 따라 모두 업무수행의 단계(일정유형)가 다르기 때문에 각각 분리하여 업무분류가 일반업무인 업무의 일정을 등록할 때와 고객사지원업무의 일정을 등록할 때 "일정유형"을 각기 다르게 지정할 수 있어야 하는 것이 이번 리뉴얼의 핵심이라고 할 수 있었다.



4. 일정 등록


업무유형(카테고리) - 업무분류(대분류) - 단위업무(프로젝트) 의 업무 구성과 일정유형의 지정이 끝나면 업무 수행에 따른 일정을 등록할 수 있다.


일정은 아래와 같이 달력에서 등록하고 관리할 수 있다.



등록된 일정은 "예정"과 "완료" 두 상태로 보여지며 제목과 내용, 분류 같은 관리 불가능한 단순한 형태가 아닌 업무분류와 단위업무, 그리고 일정유형 등 분류체계가 모두 적용되어 보여진다. 마우스 커서를 일정위에 올리면 다양한 정보가 보여지게 되도록 만들었다. 또한 팀별로 일정을 분리하여 선택된 팀의 팀원에 대한 일정만 보여지게 함으로써 그누보드의 회원시스템의 레벨에 따라 타 팀의 일정에 접근하지 못하도록 추후 수정이 가능하다.


초록색 + 버튼을 클릭하면 일정이 등록되며 일정을 클릭하면 일정을 수정할 수 있다.


일정등록 화면은 아래와 같다.



<일정 입력 편집기를 그누보드에 포함된 CKEditor와 네이버 스마트에디터로 변경하는 방법 보러가기>


위 화면은 "연구/개발"업무로 지정된 제품과 제품에 대한 개발 단위업무를 선택했을 때의 일정 등록/수정 화면이다. 일정을 신규 등록할 때는 "업무분류"-"단위업무" 목록을 보고 선택하여 지정하도록 되어 있으며 일정유형에는 "연구/개발"업무의 일정유형으로 등록된 일정유형목록이 드롭다운리스트 형태로 보여진다.



위 화면은 "공통"업무 및 "컨설팅" 업무로 지정된 단위업무를 선택했을 때의 일정 등록/수정 화면이다.



위 화면은 "고객사"로 등록된 업무분류의 단위업무를 선택했을 때 보여지는 일정의 등록/수정 화면이다.


이 시스템을 이용하면 프로젝트 또는 단위업무별로 사업이나 업무가 종료되었을 때 어느정도의 공수가 투입되었는지 누가 얼만큼의 업무를 수행하였는지, 프로젝트의 단계별로 투입된 인력 등을 산출할 수 있다. 당연히 산출된 공수에 투입인원별 공임을 곱하면 프로젝트 수행에 소요된 인건비를 계산할 수도 있다.



이 시스템을 얼마나 사용하게 될지는 모르지만... 뭔가 개발을 하고 완성(?)된 물건을 동작시켜보면 느껴지는 짜릿한 쾌감은 예나 지금이나 똑같은 것 같다. 


내 성격(?)상의 성향으로 인해 개발자가 아닌 엔지니어/컨설턴트의 길을 가고 있지만 취미 삼아 머리 속에 쌓여있던 로직을 코드로 구현하다 보면 내 몸에 개발자의 DNA도 있는 것은 아닐까 느껴지기도 한다.


<추가 2015.03.18>

실제로 사용해 볼 수 있는 환경을 공개합니다. 언제까지 공개될지는 알 수 없지만 사용해보시고 좋은 의견(?) 주시면 감사하겠습니다


<추가 2015.11.06>

다른 테스트로 인해 폐쇄합니다.


신고
이 댓글을 비밀 댓글로
  1. 일정관리 시스템 멋진것을 만드셨군요~
    요즘에 운영사 PM으로 개발사를 상대하다보니 이런 프로그램이 있어야 할것같다는 생각을 자주 합니다.
    하지만 10명이내 프로젝트라 도움이 될까도 생각해보게 되네요.
    • ㅎㅎ인원수가 적어도...일정관리와...업무수행내역 관리는 꼭 필요하죠..기록이 남지 않으면... 일하지 않은 것과 같다는게 제 원칙비스므리 한거라..
  2. 저는 예전에 꽤 비싼 해외 제품을 국내에 맞게 커스트마이징 된 툴을 사용했었는데 그것만큼 기능이 좋아보입니다. 이런툴을 잘 이용해야 하는데 제가 일하는던 예전 직장에서는 개발쪽은 잘 이용하는데 더 필요해 보이는 영업쪽의 이용이 적어서 좀 아쉬움이 있엇습니다. 자체 개발하셔서 사용하시는거라면 돈 버신 겁니다. 사용료가 만만치 않았거든요 ^^
    • 아이고..과찬이십니다...그저 제가 일하는 회사의 기술업무에 최적화? 되어 있는 거라서 범용으로 쓰기엔 부족한게 많습니다.
      프로젝트의 단계별 진행률을 간트차트로도 표현하고 싶은데...코딩실력이 딸려서 못하고 있기도하구요..

정보보안기사 자격증 취득하다.

Posted by taeho Tae-Ho
2014.12.15 23:32 나의 일

보안 쪽 일을 한지도 벌써 10년이 되어간다.


보안 쪽 일을 하며 취득한 자격증은 오늘 이전까지는 2개였다.


하나는 CISA (정보시스템공인감사사) 자격증이고 나머지 하나는 아는 사람이 거의 없는 CA의 CACES(CA공인 eTrust 엔지니어)자격증이다. CACES는 사설 자격증으로서 CA사의 보안 솔루션 엔지니어가 취득하는 자격증이다.


그리고 오늘 새로운 자격증 하나를 추가했다. 바로 국가공인자격증인 "정보보안기사" 자격증이다. (상세한 정보는 여기로)


이 자격증은 2012년 까지 KISA에서 운영하던 민간자격증인 SIS 자격증을 국가공인으로 전환하여 2013년 1회 시험을 시작으로 매년 2회 시험이 실시되는 자격증이다. 오늘(2014년 12월)까지 4회의 시험이 실시되었다.


이 정보보안기사 자격증은 정보처리기사 자격 시험과는 달리 합격율이 매우 낮은 것이 특징(?)이다.

정보보안기사의 출제 범위는 매우 넓다. 정보보안이라는 것이 IT 전분야를 다루어야 하기 때문에 범위는 넓을 수 밖에 없다. 운영체제 개론에서부터 시스템보안, 네트워크 보안, 응용보안, 암호학, 정보보호개론, 위험관리 방법론, 정보보호관련 법규 등 매우 광범위한 분야를 공부해야하는 시험이다.  (정보보안기사 출제범위는 여기로)


1차 필기 시험은 4지선다형 객관식으로 치러진다. 적당한 교재를 하나 사서 공부하면 무난히 합격이 가능하다. 나도 필기시험은 한번에 Pass했으니까.. 하지만 실기 시험은 조금 다르다. 일부 합격자들은 교재로만 공부했다는 원론적인 이야기를 하지만 내 경험에 의하면 교재만 공부해서는 2차 실기시험 커트라인 60점을 넘기기는 쉽지 않다.


2차 실기시험 출제 형태


실기시험은 먼저 시험지 앞 부분에 단답형 10문제가 출제된다. 


각 3점으로서 총 30점이 배점이 되어 있다. 문제에 따라 다르지만 하나의 답변으로 끝나는 문제도 있고 3개의 답변을 써야 하는 문제도 있다. 출제 분야는 종잡을 수 없다. 4회 시험엔 C 소스를 보여주고 버퍼오버플로를 예방하기 위한 코드를 써넣는 단답형 문제도 출제되었다. 모든 출제 범위에서 다양하게 10문제가 선택되어 출제된다.

그리고 단답형에서는 최신 보안트렌드에 대한 문제도 출제되곤 한다. 2014년을 뜨겁게 달궜던 하트블리드 취약점에 대한 문제가 3회 시험에서 출제되기도 했다.


10문제의 단답형 다음에는 3문제의 서술형 문제가 출제된다.


각 문제는 14점 배점이며 단답식 처럼 하나나 두개의 단어로 답변할 수 없는 문제가 출제된다. 적어도 3~5줄 이상 서술해야하는 문제가 출제된다. 또한 여러개의 답을 요구하기도 한다. 예를 들면 이번 4회의 시험에선 Layer 2와 Layer 3의 VPN 프로토콜을 서술하고 Layer 3의 VPN 프로콜에서 전송모드와 터널모드에 대해 서술해야 하는 문제가 출제되기도 했다. 

그리고 1회와 2회 때는 ARP 스푸핑과 같은 ARP 프로토콜의 취약성 공격에 대한 서술형 문제가 연속으로 출제되기도 했다. ARP 취약성에 무엇이 있는지와 ARP 취약점 공격 기법 그리고 방어기법 등을 모두 이해해야만 서술할 수 있는 문제들이었다.


이 서술형 3문제도 매우 광범위한 부분에서 출제되는 경향이 있다.


마지막으로는 실무형 문제 3문제(각각 14점)가 출제되며 그 중 2문제를 풀면 된다. 


두 문제의 실무형 문제 중 하나는 주로 해킹 공격에 대한 로그를 분석하는 문제 혹은 네트워크 장비의 커맨드 문제 또는 취약성 분석 도구의 사용법에 대한 문제가 출제되었다. 최근에는 2회 연속으로 SQL 인젝션에 대한 웹서버의 공격 로그를 보여주고 공격의 종류와 어떤 취약점을 공격하는 것인지, 공격에 성공했을 때 해커가 획득할 수 있는 것에 대해 서술해야 하는 문제가 출제되었으며 HTTP 프로토콜의 취약점 공격 관련 실무형 문제도 출제되었다. 실무형 문제 중 나머지 한 문제는 보안관련 법규 혹은 위험관리에 대한 문제가 출제되었다. 4회 시험에는 위험관리 기법 중 정량적 위험분석의 ALE를 구하는 문제가 출제되기도 했다. 자산가치와 노출계수를 계산하고 단일 예상손실과 연간예상손실을 실제로 계산하는 문제가 출제되었다.


이렇듯...


3점 배점의 단답형 10문제 = 30점.

14점 배점의 서술형 3문제 = 42점

14점 배점의 실무형 3문제 중 2문제 = 28점


으로 구성된 정보보안기사 실기시험에서는 사실 모두 70점이 배점된 서술형/실무형 문제 5문제가 당락을 좌우한다고 해도 과언이 아니다.


기본적으로 단답형에서 최대한 많은 점수를 확보한 뒤 (최소 20~25점)...

서술형과 실무형에서 40점 이상을 확보해야만 합격선에 다가설 수 있다


2차 실기시험의 채점 기준


사실 서술형과 실무형 6문제의 채점기준은 나도 잘 모르겠다. 정보보안기사 실기 시험의 채점기준은 일절 공개하지 않고 있다. 그렇기 때문에 채점 기준을 매시험 달리하여 합격선을 어느 정도 조정하고 있는 것으로 예상된다. 문제의 난이도가 매 시험 다르기 때문에 합격율을 조정하기 위해서는 채점 기준이 매시험 달라질 수 밖에 없을 것으로 보인다.

그리고 경험상...부분점수는 분명히 있는 것으로 보인다. 하지만 출제 기준에 의해 가장 요구되는 핵심적인 사항을 답변 했느냐 하지 못했느냐에 따라 부분점수의 부여 양상도 달라지는 것으로 보인다. 


합격 조회


1회 필기에 합격하고 오랜 시간이 지나 겨우 실기 시험에 합격하였다. 오랜 시간 머리속을 지배하던 시험..시험..시험..의 강박에서 벗어나는 것이 시험의 합격 기쁨보다 더 큰 듯 하다.









신고
이 댓글을 비밀 댓글로
  1. 시험에 합격하시고~
    정보보안기사 자격증을 받게 되신 것
    축하드립니다.^^
    좋은 하루 보내세요!
    • 감사합니다~ 즐거운 크리스마스 되시길 바랍니다. ^^
  2. 큰 성취를 이루신것 축하드립니다 그나저나 실기 문제 수준이 허걱이군요 어려운 시험을 통과하신것 먼저 축하드립니다
    • 감사합니다.. 너무 긴 시간이 걸려서 조금? 민망하기도 합니다.
    • 2014.12.29 20:00
    비밀댓글입니다
    • 안녕하세요.. 합격하셨다니 축하드립니다..저도 턱걸이라.. ^^
      어떤 교육기관에서 수강하고 계신지는 모르겠지만 취업하시기도 전에 합격하셨다니 취업에 도움이 많이 되시겠네요..
      RedCastle은 체험판이 따로 있지는 않습니다. 개인 고객은 없고 모두 공공기관이나 기업이 고객이기 때문에 그렇습니다. 아마도 그래서 답이 없을 수도 있구요.. ^^
      RedCastle은 조달가 기준으로 논리적 서버 기준으로 300~400만원 정도 합니다. 조달이 아니라면 서버의 CPU(코어)개수 기준으로 견적이 나갑니다만 가격은 영업에게 문의를 하셔야 하구요.
      아마도 교육수강 중 프로젝트를 위해서라면 Tempapory License로 잠시 테스트하시는 것은 제 선에서 해드릴 수 있구요. 다만 교육을 받으셔야 사용이 가능하실 겁니다. 메일 주소를 비밀댓글로 달아주시면 제 메일주소를 보내드릴테니 어떤 프로젝트인지와 하고자 하시는 내용을 알려주시면 지원 가능 여부를 회신드리도록 하겠습니다.
    • 2014.12.30 18:15
    비밀댓글입니다

[사이버XXX교육] 서버보안 강화를 위한 SecureOS 활용

Posted by taeho Tae-Ho
2014.10.24 18:00 나의 일

SeOS라는 시큐어OS를 접한지 10년이 넘은 지금까지 난 서버보안 관련 일을 하고 있다. 그 전에 C언어와 웹개발언어를 공부해두었고 Ingres라는 관계형데이터베이스 시스템 , 서버 및 네트워크 모니터링/관리 소프트웨어인 CA Unicenter, BMC PATROL, 백업SW인 ARCServe, 배치작업관리 솔루션인 AutoSys 그외에도 다양한 시스템소프트웨를 접한 덕분에 시큐어OS를 통한 보안강화 정책 수립에 큰 어려움이 없었다.  시큐어OS의 특성상 운영체제와 운영체제 위에서 구동되는 다양한 소프트웨어..그리고 서버에 로그인하는 관리자와 개발자들의 행동패턴을 알고 있는 것이 보안정책의 수립에 큰 도움이 된 것이다.


시큐어OS는 앞에서도 언급했 듯 운영체제와 시스템소프트웨어 그리고 웹서버 등 애플리케이션의 구조와 동작 방식을 이해하지 못하면 제대로 정책을 적용할 수 없고 누군가 대신 정책을 적용해 주었다 하더라도 위반 감사 로그 발생 시 전혀 추적을 할 수 없다.  때문에 시큐어OS 교육을 받기 위해서는 운영체제에 대한 기본적인(?) 이해가 필요하다.


우리나라의 군에서는 여러 서버보안SW(시큐어OS)가 운용 중이다. 서버의 보안을 위해서는 필수적인 소프트웨어이기 때문이다. 군의 특성 상 더욱 강력한 보안정책 적용이 필요하다. 그래서 군에 도입된 서버보안SW의 활용을 위해 교육이 개설되었고 내가 첫 "서버보안 강화를 위한 시큐어OS 활용"이라는 과목의 강의를 하게 되었다.



첫 교육인 만큼 교육의 내용은 평이한 수준으로 잡았다. 교육 대상자의 수준을 알지 못했기 때문에 유닉스/리눅스 운영체제가 갖고 있는 기본적인 취약성(취약점 아님)에 대한 악용 혹은 공격에 대해 방어할 수 있는 Baseline Security Policy에 대해 설명하고 실습을 하는 내용으로 8시간 동안 진행하였다.



서버보안SW는 일반적인 공격탐지 및 방어솔루션들 처럼 패킷을 분해하여 패킷헤더나 메시지의 내용을 시그니처라 부르는 공격패턴과 비교하여 통제하는 방식이 아닌 서버에 접속한 사용자 및 세션의 행위를 정책(Policy)을 적용하여 통제하는 방식으로 동작한다.


그렇기 때문에 정책(policy)는 특정 취약점에 종속되지 않고 현재까지 알려지지 않은 새로운 취약점으로 인한 공격도 방어할 수 있는 특징이 있다.


지금까지 수많은 기관과 기업이 서버보안SW를 도입하였지만 활용도 측면에서는 아직도 개선의 여지가 많다. 언젠가는 서버 내의 자원을 보호하기 위한 운영체제 수준에서의 강력한 보안 정책을 원하는 기관과 기업이 늘어날 것이라 예상된다. 그때는 서버보안의 강화를 위한 보안 컨설팅을 제대로 해보지 있을 수 있지 않을까 생각된다.

신고
이 댓글을 비밀 댓글로
  1. 강의를 하시다니 멋지십니다. 그렇다면 교육생들은 혹시 군인들인가요?
    궁금해집니다 ^^
    • 네..군무원...장교...부사관 등 다양했습니다...^^;;
  2. 좋은 지식들이 널리 전파될 수 있었으면 좋겠네요~
    잘 보고 갑니다~
  3. 멋지십니다. 보안전문가라니!!
    3D 코더라 ㅜ.ㅜ
    • 코딩도 보안에서 매우 중요한 포인트입니다~~~
      3D라뇨.. 개발은 IT의 기본입니다~~
      개발없이 IT가 존재할 수 없죠~
  4. 보안전문가!! 멋있으세요 ㅎㅎ

서버접근제어 및 파일접근통제를 위한 최고의 솔루션 RedCastle SecureOS 소개자료.

Posted by taeho Tae-Ho
2014.07.26 15:54 나의 일

SecureOS (서버보안SW)는 서버에 대한 접근과 서버에 접속한 사용자들의 행위를 감시하고 명령어의 실행과 파일의 수정 및 삭제를 통제할 수 있는 매우 강력하고 다양한 기능을 제공하는 보안 솔루션이다. 하지만 2014년인 지금까지도 그 활용 수준은 미미한 것이 현실이다.


내가 처음 SecureOS를 접한 것은 아마도 IMF 구제금융사태가 끝나갈 무렵인 2000년 전후였던 것으로 기억된다. 당시 국내에서 쓸만한 유일한 서버보안SW(== SecureOS)였던 미국 CA사의 eTrust Access Control이 처음 접한 서버보안SW다. 


당시 내가 일하던 '포시에스"는 CA의 리셀러였고 Ingres RDBMS와 Unicenter, BMC의 Patrol 등 외산 SW를 국내에 공급하고 기술지원을 하는 회사였다. CA가 무척이나 다양한 서버용 SW를 개발하고 판매하는 글로벌 SW 기업인 덕분에 그 외에도 많은 서버용 SW를 접할 수 있었고 시스템 SW에 대한 폭넓은 시야와 경험을 쌓는데 매우 큰 도움이 되었다. 그와중에 접하게 된 것이 바로 지금도 내가 주 업무로 담당하고 있는 서버보안분야의 핵심적인 SW인 SecureOS 였다.


이 서버보안SW는 이스라엘의 MEMCO라는 벤처에서 만든 SeOS(많은 사람들이 당시 "쎄~오에스"라고 불렀음)를 플라티늄이라는 회사를 거쳐 CA가 인수하여 eTrust Acces Control 이라는 이름으로 개명하여 공급하고 있었다.


5일 짜리 기초교육을 받고 곧바로 구미에 내려가 프로젝트를 수행해야 했지만 제품의 컨셉 정도만 이해하고 있던 당시에는 서버의 계정관리 정책이나 파일에 대한 접근 통제 정책 수립에 대한 컨설팅은 꿈도 꾸지 못했었다.




당시 처음 접했던 서버보안SW가 인연이 되어 지금도 국산 서버보안SW인 RedCastle SecureOS와 관련된 일을 하고 있다. 


이미 개발된지 10년이 넘은 RedCastle은 단언컨대 최고의 서버보안SW다. RedCastle은 SecureOS의 핵심인 참조모니터가 구현된 보안커널의 아키텍쳐나 보안커널에서의 파일접근통제 메커니즘과 파일접근통제를 위한 정책의 수립을 위한 사용자 지원 유저인터페이스등 서버보안SW의 가장 중요한 부분에서 최고의 성능과 안정성을 보장한다.


2003년 당시 RedCastle이 개발된지 얼마 안되었을 즈음에는 서버에 설치하거나 설치한 뒤 종종 서버에 장애를 유발하는 문제도 있었지만 몇년 안되어 안정성이 충분히 확보되었고 성능도 외산보다 더 뛰어날 정도로 발전을 거듭하였다. 

일례로 외산을 사용하던 고객사에서 서버의 운영체제와 DB를 업그레이드 한 뒤 외산서버보안SW를 설치하면 서버가 서비스를 할 수 없을 만큼 성능이 저하되어 RedCastle을 이용해 문제를 해결하고 임시로 임대하여 사용한 사례가 있을 정도 였다. (지금은 해당 고객사가 전사적으로 RedCastle을 도입하여 사용 중임)


얼마 전 RedCastle에 대한 소개자료를 새로 만들었다. 매번 프로젝트 수행에 필요한 산출물 위주의 문서작업이나 교육교재 (Basic Course 및 Advanced Course) 등 기술자료만 만들다 영업에 사용될 기초적인 소개자료를 만들려하니 무척이나 까다로운 작업이었다.


그런데... 반응이 신통치 않았다. 우리나라 사람들은 이런 스타일의 문서를 "싫어"한다는 것을 알기 때문일 것이다. 나도안다. 왜 나라고 우리나라 스타일을 모르겠는가? 한눈에 직관적으로 알 수 있는 그림과 표가 가득한 겉만 화려한 그런 문서말이다. 하지만 그렇게 그림과 표로 많은 내용이 함축된 문서는 보는 이들이 곡해할 수 있는 요소가 너무 많은 것이 문제다. 전혀 다른 엉뚱한 의미로 이해하는 "사고"가 발생할 가능성이 너무 높다. 그래서 누군가가 "부연 설명"을 해줘야 한다.


그래서 난 부연설명의 필요성을 최소화할 수 있는 소개자료를 만들어 보고 싶었다. 차분히 문서하나를 다 보면 충분히 이해할 수 있는 그런 문서를 말이다. 그래서 만든 문서가 바로 이 RedCastle 소개자료다.



서버보안SW(SecureOS)가 무엇인지 궁금한 사람들에게 도움이 되었으면 한다.


RedCastle 소개자료 다운로드 받기


RedCastle_소개자료_20140414(GD).pdf





신고
이 댓글을 비밀 댓글로
  1. 화려한 표와 그림으로 함축한 문서에 곡해할 여지가 많다는 말 공감합니다 심지어 보는 사람의 지식에따라 전혀 다르게 이해 되기도 하더군요. 가끔 영어원서를 보면 한국에서는 무성의 하다고 느낄 단순한 그림과 텍스트가 많았는데 언어의 장벽에도 불구하고 이해하긴 더 쉬웠던것 같습니다 ㅎㅎ

[프로젝트관리/일정관리] 세일즈 / 프로젝트 및 기술지원 업무 관리를 위한 시스템

Posted by taeho Tae-Ho
2014.05.14 13:13 나의 일


새로운 포스트 (업그레이드 되었습니다.): 프로젝트 및 일정관리 시스템 리뉴얼 (2015.01.11)


아찔한 추억


내 첫 직장은 외산 DBMS와 서버 및 네트워크 통합 관리 솔루션 그리고 서버보안SW를 판매하고 기술지원하는 일을 주업으로 하는 곳이었다. 처음 입사 후 2년은 멋도 모르고 개발일을 했었다. 당시엔 아무것도 모르는 초짜였기에 뭔가를 만든다는 재미에 빠져 개발을 했지만 지금 생각하면 혼자 공부한게 다인 초보개발자가 아무리 작은 프로젝트지만 혼자 진행했던게 얼마나 무모한 것이었는지 당시를 떠올리면 식은땀이 난다.. -.-


그 후엔 개발 프로젝트가 아닌 서버에 SW를 설치하고 구현(implementation)을 위주로 하는 일을 했다. 수없이 많은 고객사에 설치된 RDBMS에 대한 기술지원과 DB를 이용하는 애플리케이션에 대한 개발지원(EmbededSQL C, 혹은 DBMS의 자체 4GL)과 서버 및 네트워크 장비에 대한 성능/장애 모니터링, 이벤트 모니터링을 수행하는 시스템 SW를 설치하고 구현하는 프로젝트를 진행하고 관리했다.


어려움


담당하는 고객사가 늘어갈 수록 동시에 진행해야 하는 사업의 수는 늘어가고 과거 수행한 사업에 대한 유지보수 업무도 진행해야 하기에 문서나 엑셀...그리고 단순한 게시판 형태의 정보관리로는 한계가 느껴졌다. 다른 여러 프로젝트 관리를 위한 솔루션들이 있었지만 수행업무에 대한 적합성이나 편의성, 복잡성 등을 따져보면 썩~맘에 드는 솔루션을 찾긴 어려웠다.


대부분 개발프로젝트나 팀단위수행 프로젝트에 적합하고 여러 엔지니어가 공동 혹은 개별적으로 다수의 프로젝트와 유지보수 사업의 지원이력 관리 및 일정관리를 수행하기에는 적합하지 않은 경우가 많았다.


개발


그래서 직접 만들기로 했고 틈틈히 일을하는 와중에 코딩을 해봤다.

리눅스 서버에 아파치웹서버와 PHP 그리고 MySQL을 올려 간단한 DB설계를 하고 코딩을 시작했다. 실력도 딸리고~ 시간도 부족하고 해서 팀과 팀원 관리는 제로보드의 것을 그대로 연동했다. 게시판이 필요할 경우 그대로 쓸 수 있으니 일석이조였다.


고객사관리


고객사는 고객사의 업종(나중에 고객사의 분류를 위해)과 고객사명 그리고 고객사의 유니크한 ID로 구성된다.

이름으로 검색하기와 추가하기가 가능하다. 


고객사 이름을 클릭하면 해당 고객사에서 수주한 프로젝트(사업) 관리 페이지로 연결된다. 소프트웨어나 하드웨어의 경우 하나의 고객사에서 여러 차례에 걸쳐 구매를 하기 때문에 각각의 프로젝트를 분리하여 관리해야 한다.




프로젝트 관리


솔루션벤더의 프로젝트는 개발 프로젝트와는 성격이 많이 다르다. 한명의 엔지니어가 수십개의 프로젝트를 진행할 수 있기 때문이다. 당연히 상주지원은 하지 않는게 원칙이어야 한다. 


프로젝트는 고객사, 프로젝트명, 담당 엔지니어, 프로젝트의 진행상태로 검색이 가능하다.  또한 프리세일즈 단계의 프로젝트는 수주 가능성에 따라 여러 1순위, 2순위, 3순위 등으로 구분하여 관리하여야 한다.


또한 프로젝트가 종료되면 유지보수사업을 신규로 등록하여 수행중인 프로젝트와 유지보수사업을 분리하여 관리하고 일정도 각기 등록할 수 있다.



신규 프로젝트가 영업단계에 돌입하거나 수주하여 사업을 수행하게 되면 고객사에 프로젝트를 추가한다. 담당 영업 및 엔지니어, 수주 금액, 프로젝트 상태 등의 정보를 입력하고 킥오프 일자 및 사업 종료시 완료(검수)일자를 입력한다. 프로젝트에 대한 상세 내용은 하단에 입력하여 추후 조회할 수 있도록 한다.


프리세일즈 단계의 사업은 영업팀에게만 공개되며 [진행상태]를 "사업진행"으로 변경하고 엔지니어를 지정하면 담당엔지니어에게 프로젝트가 보이게 되고 지원일정을 등록할 수 있다.


이 프로젝트는 고객사 뿐만 아니라 사내에서 수행하는 여러 업무를 분류하여 등록하면 내부 업무에 대한 관리도 가능하다. 현재 이 시스템은 프로토타입 수준으로 개발되어 있기에 보다 보강하여 개발한다면 상업용으로도 써먹을 수 있지 않을까 싶다.




일정관리


프로젝트가 등록되면 영업담당자 및 엔지니어는 프로젝트를 기반으로 일정을 등록한다. 등록된 일정은 아래와 같이 캘린더에 표시되는데 현재는 [고객사/엔지니어] 형태로 캘린더에 표시되어 엔지니어나 담당영업사원이 일자별로 어느 고객사에 기술지원 혹은 세일즈를 진행하는지 한눈에 알 수 있도록 하고 있다.


화면 상단에 팀을 구분하여 볼 수 있도록 하고 있다. 내가 속한 팀의 일정이나 개인의 일정 혹은 타 팀의 일정을 볼 수 있다.


일자를 클릭하거나 일정을 클릭하면 아래와 같은 창을 띄워 신규 일정 등록 혹은 수정을 할 수 있다.

[고객사명]의 찾기 버튼을 눌러 일정을 등록할 프로젝트를 선택한 뒤 일정의 [제목]과 오전 [직출여부], 업무의 유형 등을 선택하여 저장하면 캘린더에 표시되도록 되어 있다. 업무를 수행한 뒤 일정을 수정하여 업무(작업)의 [시작시간]과 [종료시간]을 선택하면 [소요시간]이 자동으로 계산되어 저장되며 [일정유형]을 "완료"로 변경하면 캘린더에 파란색으로 표시되어 처리완료한 일정임을 알 수 있다.



위의 화면은 고객사명을 "병원"으로 검색하여 프로젝트를 조회한 화면이다.

입력된 데이터는 추후 통계에 사용될 수 있다.


캘린더에서는 아래와 같이 일정에 마우스를 올릴 경우 일정의 내용을 볼 수 있도록 처리했다. 일일히 일정을 클릭해 창을 열지 않아도 되도록....


추후 특정 프로젝트를 선택하여 지원 내역(프로젝트 수행내역)과 총 지원 시간을 합계내어 볼 수 있도록 했다. 적자를 보는 프로젝트가 아닌지...투입된 인건비가 얼마인지를 계산할 수 있다.


마이페이지


마이페이지에는 아래 처럼 "예정"으로 등록된 일정을 보여주고 담당자가 본인으로 되어 있는 프로젝트 및 유지보수사업의 목록이 보여진다. 


마무리


프로토타입 수준의 이 시스템은 30여명의 엔지니어들이 사용하고 있으며 꽤나 유용하게 쓰이고 있다. 보완하고 싶은 것은 많지만 귀차니즘으로 인해 엄두를 못내고 있는 실정이다. JSP 버전으로 바꾸고도 싶고 영업정보를 추가하여 영업관리 기능을 넣고 싶기도 하고 연구소의 제품개발일정 관리 기능도 추가하고 싶기도 하다.


때론 이걸 제품화해서 팀오피스 처럼 ASP 사업을 해보고 싶기도 하다. 틈새시장은 충분할테니까... 머리속에 축적된 세일즈, 프로젝트, 유지보수 및 기술지원 업무 관리 플로우를 실제로 구현하고 싶지만 나의 코딩 속도는 너무 느리고 코드 설계는 이젠 버겁다. T.T


하루가 48시간만 되면 24시간은 일상생활과 회사에... 나머지 24시간은 여기에 투자 해볼텐데... ^^



신고
이 댓글을 비밀 댓글로
  1. 일을 하다보면 좋은 도구가 필수인데~~~
    매우 유용하겠네요^^

netsec-kr 2014 - 효과적인 내외부 인력의서버 접근 통제 구현

Posted by taeho Tae-Ho
2014.05.01 15:27 나의 일

netsec-kr 2014에서 세션하나를 맡아 주제발표를 하게 되었다. SecureOS (RedCastle)을 활용한 서버보안 강화 분야의 일을 주로 하다보니 보다 폭 넓은 주제를 맡은 것이 꽤나 부담이 되기도 했다. 하지만 서버로의 접근통제와 접속한 이후의 서비스 및 사용자 세션의 행위 통제에서 벗어나 내부 및 외부 인력의 서버에 대한 접근 통제란 주제에 대해 보다 폭넓게 고민해 볼 수 있는 계기가 되기도 했다.


NETSEC-KR 2014는 4월24일(목)~25일(금) 양일간 코엑스 3층에서 진행되었고 "창조경제를 위한 정보보안"이라는 주제로 열렸다. (조금 뜬금없기는 하지만.... ^^)



첫날 오후 금융보안 트랙의 세번째 세션이다.



그리고 몇일 뒤...

메일링 신청해놓았던 보안뉴스에서 날아온 메일에 내가 발표했던 세션에 대해 기사가 스크랩돼서 날아왔다. 그래서 보안뉴스 사이트로 가보니....



음... 정말..핵심만 잘 요약한 기사였다..

기자분의 요약이 내가 횡설수설 발표한 것보다 낫다는 생각이... -.-


그리고 요약을 잘 해주어서 인지...많이 본 기사 부문에서 14위(?)엔가 랭크되어 있었는데.. 몇일 뒤 5위까지 올라가 있었다.



SecureOS 에 대한 주제라면 더 잘할 수 있었겠다는 아쉬움..?? 도 있었지만 그래도 재미있는 경험이었다.




신고
Tags
이 댓글을 비밀 댓글로

IT 솔루션 기업의 조직관리 및 프로젝트 관리에 대한 올바른 방향 (CMMI)

Posted by taeho Tae-Ho
2013.03.06 10:32 나의 일

전에 기술지원조직의 업무관리에 필요한 간단한 프로젝트 및 일정관리 시스템 개발에 대한 포스트를 기록한 적이 있다. 그리고 시간은 흐르고 흘러 6년이 되어 간다. 지금도 그 시스템은 우리 부서 30여명의 엔지니어들이 잘 사용하고 있다. 비록 많은 버그와 부족한 점이 있지만 기본적인 프로젝트관리와 일정(캘린더)이 확실하게 연결되어 있어 기본기능만큼은 충실하기 때문이다. 그리고 영업부서로부터 엄청나게 밀려오는 신규사업과 유지보수사업 그리고 영업지원에 대한 요구로 인해 사용하지 않고는 못배길 만큼 엔지니어들이 관리해야 하는 프로젝트와 기술지원 일정이 넘쳐나기 때문이기도 하다.

* IT 솔루션 기업의 핵심 부서

내가 지금 근무하는 기업은 IT솔루션, 그중에서도 SW 개발 기업이다. 그리고 SW 중에서도 시스템SW이자 보안SW다. 그리고 SI 사업으로 고객의 요구에 맞춰 그때 그때 수정하여 제공하는 SW가 아닌 패키지 SW다. 즉 한번 만들어서 지속적으로 판매/설치/컨설팅/유지보수가 반복되는 상용SW다. 그리고 계속적인 버전 업그레이드와 재설치, 보안정책 수립에 대한 기술지원과 컨설팅이 이루어진다.

이러한 솔루션 기업(하드웨어도 포함)은 기업내의 여러 조직 중 세개의 조직이 핵심조직이다. 바로 영업-개발-기술지원/컨설팅 부서다.

영업조직은 IT솔루션 기업에서 가장 중요한 조직이다. 제품이 아무리 뛰어나도 영업력 부재라면 그 기업은 십중팔구 사라진다. 존재의 여부마저도 아무도 모르게 망해 없어지는 경우가 허다하다. 반면 제품의 수준은 형편없어도 오랜시간 생명을 유지하며 자신의 존재를 뽐내는 참 대단한 기업도 다수 존재하는데 이런 기업들은 확실한 인맥을 가진 영업맨이 한두명은 있게 마련이다. 제품의 기술력이 우수하고 시장에서 인정받아 수요가 꾸준한 제품이라면 직접영업보다는 간접영업을 하는 것이 보다 효율적이다. 이런 경우에는 직접영업조직과 인바운드영업을 담당하는 조직을 별도로 가져가는 것이 효과적이다. 그리고 매출규모가 더 커진다면 마케팅부서를 별도로 두거나 영업조직의 하위에 두는 것도 효과적일 수 있다.

개발조직은 SW개발자 집단이다. 제품의 품질을 좌우하는 무척 중요한 조직이다. 어느정도 영업이 이루어져 제품의 판매가 이루어지기 시작하면 개발조직과 영업조직간의 여러가지 갈등이 발생하기 시작하는데 이 싸움이 어떻게 진행되느냐에 따라 기업이 흥하느냐 망하느냐가 결정되기도 한다. 어느정도의 균형은 이루어야 하겠지만 일반적으로 개발조직의 제품개발 방향은 영업조직과 기술지원/컨설팅 조직의 요구에 맞추어가는 것이 바람직하다. 고객과의 접점에서 고객의 요구사항을 직접적으로 전달받는 즉, 시장의 요구사항을 피부로 체험하는 조직의 요구에 제품 개발 방향을 맞추지 않고 나름 개발자들의 "환상"에 방향을 맞춘다면 제품은 시장에서 점점 외면받게 되며 결국 도태될 가능성이 매우 높아진다.

기술지원/컨설팅조직은 우리나라에서는 그 중요성을 제대로 인정받지 못하는 조직이다. 우리나라의 IT솔루션 기업에서 기술지원을 담당하는 엔지니어들은 대부분 일정기간이 지나면 영업조직으로 옮기거나 조금 규모가 있는 SI기업으로 이직하는 경우가 많다. 그만큼 IT솔루션 기업에서 엔지니어를 우대해주지는 않는다. 때문에 훌륭한 솔루션을 개발하고 팔아 놓고도 제대로 기술지원을 하지 않아 나쁜 평가를 받게 되고 결국엔 그저그런 솔루션으로 시장에서 근근히 살아남아 겨우 명맥만 유지하는 경우가 너무도 많다. 그 이유가 바로 "엔지니어의 기술 수준이 형편없이 낮고 경험이 부족"하기 때문인데 기술자를 천대시하는 역사적 전통(?)이 현시대를 살아가는 사람들에게 영향을 주기 때문인 것으로 보인다.

나머지 조직은 영업-개발-기술지원 부서를 서포트(Support)해주는 역할을 수행해야 한다. 이 대목에서 많은 다른 조직의 직원들이 기분나빠할 수도 있다. 하지만 그럴 필요는 없다. 기업내에서 불필요한 조직(?)은 없다. 다만 이 세개의 조직은 기업의 근본적 가치인 "돈"을 버는데 필요한 업무를 수행한다는 의미에서 핵심부서라는 이야기이기 때문이다. 군대로 치자면 "전투병과" 라는 이야기다.

프로젝트관리


* 영업-개발-기술지원/컨설팅 부문을 아우르는 프로젝트 관리 방향 (CMMI)

보통 PMS(프로젝트관리시스템)를 개발할 때 보통은 사업수행의 관점에서만 생각하는 경우가 많다. 프로젝트를 수주한 이후 프로젝트가 시작되는 시점부터의 업무만을 프로젝트관리시스템의 관리 대상으로 보는 것이다. 하지만 프로젝트는 영업조직에서 고객사의 사업 준비를 포착하는 단계에서부터 이미 시작된다고 봐야한다. 그렇지 않고 사업을 수주한 시점을 프로젝트의 시작으로 보게되면 영업단계에서 소요되는 시간과 인건비를 고정비로 보게 되고 사업 수주를 위해 지출한 상당한 비용의 접대비와 인건비가 원가에 제대로 반영되지 않아 사업의 수익성이 왜곡되는 결과를 초래하게 된다.

또한 비록 패키지성 솔루션을 만드는 개발조직이라 할 지라도 특정 사업의 필요에 의해 특정 기능이나 모듈을 개발하는데 투자하는 인건비는 제품의 개발원가가 아닌 사업수행의 원가에 포함시켜야 하는데 영업단계의 비용과 마찬가지로 자칫 개발부서의 인건비를 고정비로 보게되면 프로젝트의 수익성이 왜곡되어 적자성 사업이 흑자 사업으로 둔갑하는 결과를 초래하게 된다. 

기술지원/컨설팅 조직 또한 마찬가지다. 한명의 엔지니어나 컨설턴트가 동시에 한개의 사업만을 수행한다면 인건비 산정과 프로젝트에 원가 반영이 쉽겠지만 한명의 엔지니어가 두개 이상의 사업을 수행하게 되면 어느 사업에 얼마만큼의 인건비가 소요되었는지를 제대로 반영하기는 사실상 어렵다. 

만약 프로젝트의 시작을 영업 초기단계로 설정하고 제품의 신규기능 및 수정될 기능에 대한 개발 과정을 프로젝트의 업무단위로 보며 개발자와 엔지니어/컨설턴트의 개발일정, 지원일정을 프로젝트의 수행과정으로 본다면 영업-개발-기술지원/컨설팅의 단계로 이어지는 하나의 프로젝트가 완성되며 제대로된 투입인력 산정(M/M)과 소요비용의 산출이 가능해진다.

또한 프로젝트별 인력투입현황과 현재 조직의 업무 포화도, 직원 개인간 업무 수행 시간의 비교와 업무 유형별 투입시간의 파악이 가능해지기 때문에 인력 부족 여부는 물론 앞으로의 인력 채용 계획을 수립하는데도 무척 효과적일 수 있다.

이렇게  IT분야의 개발단계를 명시하고 업무 프로세스의 관리 능력을 평가하는 평가모델이 바로 CMMI 다. 사실 서양 아이들(?)이 잘하는 것이 다양한 경험을 바탕으로 각 분야의 지식을 종합/정리하고 새로운 이름을 붙이는 짓(?)이다. ISO 모델이 그렇고 BS7799 등이 그렇다. 대부분 이미 수행하고 있는 세부 단계들을 하나로 엮어 체계화한 것이 이런 표준 모델이다.

정작 새로운 이름으로 표준을 정립한 서양 아이들은 조용한데 이러한 모델들이 우리나라에 도입될 때 마치 전혀 새로운 것인양 호들갑을 떨며 대단한 새로운 개념인것처럼 그리고 그것을 자신이 먼저 알고있다는 근자감에 사로잡혀 잘난체하는 일부 사람들을 보면 씁쓸할 따름이다.

연관포스트 : 프로젝트 및 일정관리 시스템 리뉴얼


신고
이 댓글을 비밀 댓글로

통합 계정관리 및 권한관리 시스템 구축의 핵심

Posted by taeho Tae-Ho
2012.12.22 23:43 나의 일

통합계정권한관리(IAM)

요즘들어 통합 계정관리 시스템을 재(?)구축 하는 사업이 심심치 않게 발주되고 있다. 매우 오래 전 부터 대기업과 금융기관들을 중심으로 구축된 통합계정관리시스템은  IT거버넌스 측면에서 체계적인 IT시스템의 운영/개발/사용에 중 발생하는 사용자 계정의 라이프사이클에 대한 통합 관리 체계를 구축하기 위해 필히 갖추어야 하는 효과적인 계정관리 체계다.

통합계정관리시스템은 조직 내부에서 운영되는 시스템에 존재하는 모든 계정에 대한 라이프사이클과 계정을 통해 서비스 및 자원에 접근하는 행위를 적절하게 통제하여 보안성을 높이고 생산성을 관리할 수 있도록 해주는 시스템이다.

말은 참 쉽다. 

하지만 대부분의 조직에서 기 구축된 통합계정관리 시스템을 효과적으로 사용하는 예는 매우 드물다. 통합계정관리 시스템을 통해 편의성과 보안성을 모두 얻어야 하지만 그렇지 못한 경우가 대부분 이다. 그 이유에 대해 이야기하자면 우리나라의 조직문화와 관리자의 마인드, 그리고 프로젝트관리에 대한 격한(?) 토론이 되기 때문에 왜 제대로 운영되지 못하는가는 이야기하지 않기로 한다.

통합계정관리시스템은 크게 두가지로 구분된다.

먼저 IT부서가 아닌 일반 부서의 사용자들에게 부여되는 서비스 시스템의 계정에 대한 계정통합관리시스템이 있다.

이 통합계정관리시스템은 조직은 전 구성원이 사용하게 되며 인사시스템에 존재하는 모든 사용자와 1대N의 관계를 갖는다. 즉 한사람이 최소 하나 이상의 서비스애플리케이션에 계정을 갖고 있는 것이다. 최근에는 대부분 웹 애플리케이션이며 그룹웨어, ERP, CRM, Email 등의 서비스에 접속하기 위해 사용되는 계정을 통합관리하는 시스템이다. 당연이 싱글사인온(SSO)과 연동이 되어야 하며 대부분 AD(액티브디렉토리) 혹은 기타의 LDAP과 연계되어야 하는 시스템이다.

이 포스트에서 언급할 통합계정관리는 이 수준의 통합계정관리가 아닌 IT부서에서 운영중인 서버에 존재하는 서버 계정에 대한 통합계정관리다.

서버에 존재하는 계정을 통합관리해야하는 이슈는 몇년 전 발생한 농협의 보안사고로 다시 한번 크게 부각되었다. 당시 농협의 허술한 서버 계정에 대한 관리 그리고 270여대의 서버에서 일시에 삭제되기 시작한 파일에 대한 접근 권한 통제 미흡이 사고가 발생하는데 큰 기여(?)를 하였으며 겉으로는 "북한의 테러"로 결론을 내렸(?)지만 구체적으로 말하자면 "계정권한관리의 실패"로 귀결되었다.

당시 삭제된 파일들은 대부분 root 권한이나 DB관리자, 응용프로그램 관리자 계정의 권한이 있어야만 삭제할 수 있다. 결론적으로 말하자면 서버의 Super User 계정인 root의 권한으로 270여대의 서버에서 파일시스템을 "밀어~"버리는 명령을 실행하여 발생한 사고 였다.

이렇듯 적게는 수십대에서 많케는 일천대가 넘는 서버에 존재하는 특별한 권한을 가진 계정들에 대해 어떻게 보안을 강화하고 체계적인 권한관리를 하여야 하는가에 대한 고민이 최근(2012) 불기 시작한 제대로된 IAM(Identity and Access Management) 을 구축하려는 움직임으로 이어지고 있는 것이다.

IAM 구축에 필요한 것은?

이전까지 통합계정관리의 범위는 계정에 대한 라이프사이클의 범주를 벗어나지 않았다. 그 이유는 지금도 마찬가지지만 대부분의 IT 기획과 운영부서에서는 서버에 계정이 생성되고 해당 계정에 대한 패스워드 관리를 넘어서는 "서버내 계정의 서버 내부 활동에 대한 감시와 통제"에 대한 방법론을 알지 못하기 때문이다.

그래서 대부분의 보안 감사를 수행하는 감사인력들은 서버의 경우 "패스워드 통제"에 주요 포커스를 두고 감사를 수행한다. 서버 내의 운영체제 계정에 대해 패스워드의 복잡성을 제대로 적용하는지, 주기적인 패스워 변경을 하고 있는지, 관리자 계정의 비밀번호를 여러 사람이 공유하지는 않는지 등을 검사한다. (최근에 들어서야 서버 내에서 작업한 내용에 대한 상세한 작업 기록을 보관하는지를 검사하기 시작했다.)

그리고 아직까지 통제하지 못하는 것이 바로 서버에 생성된 계정에 대한 "서버 내부에서의 행위"에 대한 실시간 통제다. 이는 SecureOS를 설치하면 가능하다. 즉 IM솔루션과 서버보안SW가 연동되면 제대로된 IAM을 구축할 수있게 된다. 물론 IM솔루션과 서버보안SW를 제대로 연동하자면 솔루션의 설치만으로는 불가능하다.

제대로된 IAM을 구축하자면 최소한 IM솔루션과 서버보안SW가 필요하다. 그리고 추가적으로 필요한 것은 바로 "계정에 대한 관리 정책"이다.

IM솔루션과 서버보안SW가 있다 하더라도 서버에 root계정으로 직접 로그온한다던가 시스템관리자와 DB관리자 그리고 웹 관리자 및 응용프로그램관리자, 개발자 등의 역할을 명확하게 정의하고 구분하여 운영하지 못하고 시스템운영자와 개발자간의 파워게임이 심하거나 개발자가 root 계정, DBA계정을 마구 사용하는 등 권한분리가 되어 있지 않다면 제대로된 IAM 구축은 거의 불가능하다고 보는 것이 옳다.

즉 IAM을 구축하려면 먼저 내부 조직의 역할분리와 개인계정 사용의 생활화가 먼저 정착되어야 한다.

IAM 구축의 범위와 핵심

최근의 IAM 구축 사례를 보면 그 범위가 이전의 IM 구축 사례와는 차원이 다르다.

간단하게 그림으로 표시하면 다음과 같다.

통합 계정 권한 관리 IAM

전통적인 IM의 구축범위에 단점은 많지만 최근 유행하고 있는 서버접근제어 솔루션과 서버보안SW를 연계하여 IAM을 구축하는  형태가 주를 이루고 있다. (여기에는 많은 함정이 기다리고 있긴 하다.)

가장 중요한 것은 IM에 의해 서버에 계정이 만들어질 때 생성되는 계정에 대하여 서버내의 어떠한 자원에 대한 접근권한을 부여하거나 혹은 접근을 차단하도록 서버보안 정책을 설계하고 수립할 것인가 하는 점이다. 이 단계의 작업이 IAM 구축의 성패를 좌우한다고 해도 과언이 아니다. 

계정에 대한 생성과 삭제까지의 라이프사이클을 관리하는 것은 지금까지 구축한 수많은 IM의 구현범위와 다를 바가 없는 것이다. 기존 IM의 범주에 서버보안SW의 파일접근 및 명령실행 통제 기능을 이용하여 계정 생성 시 자동으로 서버내의 파일에 대한 접근(읽기/수정/삭제/생성 등) 권한을 어떻게 자동화하여 적용할 것인가가 가장 중요한 포인트라 할 수 있다.

과연 제대로된 IAM의 구축에 성공하는 기업은 얼마나 될지..자못 궁금하다.



신고
이 댓글을 비밀 댓글로
  1. 잘보고 갑니다. 지금은 어떻게 구축하고 계신지 너무 궁금합니다. ^^
    • 계정관리(IM/IAM) 시장이 엉망이 되었습니다. ^^ 전문계정관리 솔루션이 아닌 제품들이 빈약한 계정관리 기능을 내세워 시장을 침범하고 있는 상황이죠. (시스템계정관리분야) 그래서 전 계정관리 쪽 일은 하지 않고 있습니다.
      댓글 감사드립니다~

IT 특급기술자가 되다..

Posted by taeho Tae-Ho
2009.12.05 12:58 나의 일

전산(IT) 분야에도 기술자격 인증제도가 시행됐다. 말도 많고 탈도 많지만 어쨌든 나의 경력을 공식적으로 나라에서 인증해준다는데 마다할 이유는 없지 않은가...

1996년부터 시작된 엔지니어의 길... 이제 13년이 넘었지만 과연 13이라는 숫자에 걸맞는 실력을 갖추었는지는 곰곰히 되돌아보고 반성할 점은 뼈저리게 반성해야할 듯 싶다.

운영체제...데이터베이스...ITSM...보안...그리고 몇몇 개발분야를 두루 맛(?)보았지만 특별하게 "난 이분야의 전문가다"라고 자신있게 말할 수 있는 분야는 무엇일까....

IT직종이라는 특수성으로 인해 계속공부하지 않으면 뒤쳐질 수 밖에 없고...나이를 먹을 수록 젊은 엔지니어에 비해 새로운 기술에 대한 습득 속도가 떨어진다는 단점을 극복하면서 "경험"이라는 우수한 성능의 무기를 계속 갈고 닦아야 하는 것이 바로 나... 시니어엔지니어의 숙제다.


신고
이 댓글을 비밀 댓글로
  1. 글에 진정성이 느껴지네요. 많은걸 느끼고 갑니다.
    • 오랫만에 쓴 글을 보니...여기저기 오타도 보이네요.. 좋게 읽어 주시니 감사할 따름입니다.

엔지니어 및 프로젝트 일정관리 시스템 개발

Posted by taeho Tae-Ho
2008.08.07 12:40 나의 일


포스트 내용이 훼손되어 새로 씁니다. 티스토리가 불안~불안~ ^^ (http://blogger.pe.kr/391)


나는 엔지니어다.

내가 하는 일을 뭐라고 불러야 할지 지금도 모르겠다. 혹자는 SE(시스템엔지니어)라고도 하고 혹자는 컨설턴트라고도 한다. 일이 일이니 만큼 여기저기 돌아다니면서 일을 하게 되고 이런 저런 다양한 업무가 실행중인 서버들을 만지게 된다. 운영체제도 다양하고 하드웨어도 다양하고 네트워크도 복잡한 곳이 많다. 내가 가본 기업이나 관공서만 해도 수백 곳이 되지 않을까 싶다.

 

그렇게 많은 곳을 다니며 이런 저런 프로젝트를 진행하면서 만난 사람들은 대부분 나와 같은 엔지니어들이다.(개발자를 볼일은 자주 있지 않다) 엔지니어들은 적어도 하루에 하나 이상의 프로젝트에 투입되어 일을 하게 된다. 1~2회의 방문으로 시작과 끝이 나는 곳이 있는가 하면 많게는 백 회 이상 즉 백일 이상 방문 혹은 상주하여 진행해야 종료되는 프로젝트도 있다.

개발자의 경우 WBS니 뭐니 하는 개발방법론에 의해 일정과 개발 과정이 관리되며 큰 SI업체든 작은 개발업체든 일단 프로젝트에 투입되면 비교적 일정과 업무 단계가 잘 관리되는 경우가 많다. 하지만 동시에 여러 프로젝트를 떠돌며(?) 지원업무를 수행하는 엔지니어의 경우 업무 수행 과정과 단위 업무 혹은 프로젝트의 관리가 제대로 이루어지는 것을 보지 못했다. 더군다나 엔지니어들이 속한 기업들은 대기업보다는 소규모의 중소기업이 많다. 그렇기 때문에 아무래도 중소기업이나 벤처기업의 경우 엔지니어와 엔지니어들이 수행하는 프로젝트에 대한 관리가 소홀한 경우가 많은 것이다.

 

하지만 시작과 끝이 명확하고 업무 단계도 투명한 개발프로젝트와 달리 특정 하드웨어 혹은 S/W 솔루션의 기술지원을 위해 프로젝트 투입되는 엔지니어는 프로젝트의 시작과 끝이 명확하지 않은 경우도 많고 프로젝트 특성에 따라 동일한 규모의 두 개의 프로젝트라 하더라도 투입 인력과 시간이 천차만별인 경우가 많다. 따라서 더욱 철저한 인력과 시간관리가 필요하다 할 수 있겠다.

 

솔루션의 가격은 정해져 있는 상태에서 과도한 엔지니어의 투입은 인건비의 증가로 이어지고 결국에는 수입을 초과하는 인건비의 투자로 인해 적자로 이어지지만 그에 대한 비용의 산출을 위해 기술지원에 대한 근거를 남기지 못하는 경우가 대부분이다. 게다가 SI업체와 함께 시작한 프로젝트가 종료되어 SI업체의 개발자들과 프로젝트 팀은 모두 철수하였는데도 솔루션 업체의 엔지니어는 지속적으로 투입되어 일을 마무리(?)하고 있는 경우고 허다하게 보아왔다.

 

하지만 어느 업체도 그에 대한 문제를 심각하게 인식하거나 왜 그러한 경우가 발생하였고 그런 경우 얼마나 많은 추가적인 비용이 투입되었는지를 산출하여 제품의 원가에 반영하는 경우를 보지 못했다.

 

나는 그냥 엔지니어다.

 

기술지원 업무를 수행하는 엔지니어의 업무를 관리할 방법론을 만들만한 지식은 없다. 하지만 궁하면 통한다고 했던가... 내 엔지니어 업무 수행 경험을 바탕으로 내가 몸담고 있는 회사에서 사용할 간단한 기술지원 업무 관리 시스템을 만들어 보았다. 아마도 대부분의 솔루션을 판매하고 기술지원을 하며 유지보수를 수행하는 엔지니어를 보유한 기업에서 사용할만한 시스템을 목표로 만들었다.

 

특별히 설계도 없었고 누구와 협의도 하지 않았다. 그냥 혼자 만들었다. 그만큼 단순하고 비 체계적일 수 있지만 단순한 만큼 쉽게 사용할 수 있다.

 

로그인


프로젝트가 팀장 혹은 담당영업에 의해 등록되면 엔지니어들이 프로젝트의 수행 혹은 기술지원을 위해 일정을 등록할 수 있다. 프로젝트가 등록되지 않으면 엔지니어는 외근 혹은 내부에서 프로젝트 수행에 대한 일정을 등록할 수 없다.

등록된 일정은 다음과 같이 달력화면에서 어떤 프로젝트에 누가 기술지원을 수행하고 있는지 한눈에 볼 수 있다.

 


주 단위, 엔지니어 개인, 팀 등의 구분에 의한 보기는 하지 않았다. 현재 엔지니어가 9 명인데 사용하는데 전혀 불편함이 없다.(물론 나만의 생각~~~ ㅋㅋ) 그래서 그런 기능은 넣지 않았다.

 

달력에 표시된 일정 중 하나에 마우스를 올리면 다음과 같이 내용이 상세하게 보이는 팝업창이 보인다. 궂이 일정을 클릭하여 수정모드로 들어가지 않아도 내용을 마우스의 움직임 만으로 볼 수 있도록 하였다.



이렇게 등록된 일정이 누적되면 특정 고객사 혹은 프로젝트에 지원된 내역을 조회할 수 있게 된다. 어느 프로젝트에 얼마만큼의 기술인력이 투입되었는지 통계가 가능하고 언제 처음으로 엔지니어가 투입되었고 언제 설치를 진행하였으며 언제 어떤 문제가 발생하여 장애지원을 했는지 등 다양한 검색을 할 수 있다.



기술지원현황조회



위의 화면은 모 대학에 대한 기술지원 이력을 조회한 화면이다.조건에 따라 장애지원,설치,엔지니어 등 다양한 조건을 이용해 기술지원이력을 조회할 수 있다.

 

하나의 프로젝트가 검수단계를 거쳐 완료되면 무상 유지보수 기간에 들어간다. 또한 무상 유지보수기간이 종료되면 유상 유지보수 계약을 유도하여 매월 일정액의 금액을 받고 정기점검과 이따금씩 교육 혹은 업그레이드를 실시해주게 된다.

 

그래서 유상 유지보수계약이 된 고객사 및 프로젝트를 별도로 관리할 수 있도록 다음과 같이 유상 유지보수 계약 고객사 및 프로젝트를 관리할 수 있도록 하였다.

물론 엔지니어가 일정을 등록할 때에는 프로젝트가 진행중인 일정인지 유상 유지보수 계약이 되어 있는 고객사에 대한 기술지원인지를 구분하여 일정을 등록할 수 있도록 하였다.

신고
이 댓글을 비밀 댓글로