태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

나의 일 (28)



심사원의 자질(?)이 논란이 되자 2015년 신설된 ISMS인증심사원 선발시험에 응시해 취득한 ISMS인증심사원 자격과 기존의 PIMS인증심사원 자격의 통합되었다. 그로인해 작년 부터 숙원 사업(?)이었던 ISMS-P 인증심사원 자격을 취득했다. ISMS 인증심사원 자격만 갖고 있었기에 자격전환 시험을 치러야 했고.. 자격전환교육(2일)을 이수하고 만만하게 보고 치렀던 시험에서 1차 낙방을 겪었다.


시험의 난이도는 상상이상으로 어려웠고 대부분의 지인들이 증언하는 불합격 인증은 70점 커트라인에 합격율이 2~3%에 지나지 않는다는 소문이 사실임을 입증해주었다. 말도 많고 탈도 많았던 1차 시험이었다.


남은 기회는 두 번... 세번째 시험까지 치르기 싫어 도서관을 들락거렸고 난이도 조절을 했는지 조금 수월하게 2차 시험을 치렀고 무난히 합격할 수 있었다. 도서관을 드나들면서 지난 1회 ISMS인증심사원 시험준비할 때가 자꾸만 생각났다. 비슷한 방법으로 시험준비를 한 뒤 응시했고...


그리고 오늘.... 드디어 ISMS-P 인증심사원 자격증을 이메일로 받았다.


ISMS-P 인증심사원 자격전환 시험 합격 문자 및 자격증ISMS-P 인증심사원 자격전환 시험 합격 문자 및 자격증


전환시험 합격 후 1개월 하고도 20일만에 받은 ISMS-P 인증심사원 자격증이다. 2015년 ISMS인증심사원 필기시험 1회에 합격하여 ISMS인증심사원 자격 취득 3년만에 개인정보보호 관리체계 인증심사(ISMS-P)에도 참여할 수 있는 자격을 보유하게 되었다.


이젠 또 무엇에 도전해야 할까...




20년 넘는 시간의 직장생활을 그만두고 자유롭게(?) 일한지 만으로 2년이 되어간다.


20년...


지난 20년간 모두 4개의 회사를 경험했다. 두 회사는 합해서 2년을 채우지 못했고 두 회사는 각각 8년과 10년이 넘는 시간동안 재직했다. 그리고 그 안에서 대여섯 개의 본부와 팀을 경험했다. 그리고 운이 좋았는지 초반 4~5년이 지난 뒤 부터 때로는 작고 때로는 큰 조직을 맡아 리더의 역할을 수행할 수 있었다. 그리고 그 긴 시간동안의 경험을 바탕으로 팀과 본부급의 조직에서 리더가 갖추어야할 조건들에 대해 참 많은 것을 깨닫는 시간이기도 했다.


어떤 조직이든 조직의 리더에게는 리더쉽이 필요하다. 하지만 중요한 것은 조직의 리더가 갖추어야할 역량이나 능력은 조직이 처한 상황이나 구성원의 특징 혹은 조직의 분위기에 따라 모두 다르다는 점이다. 전에도 쓴 적이 있지만 (보러가기) 언론이나 자기계발서와 같은 책에서 떠드는 현실과 동떨어진 리더쉽을 마음에 담아두고 따라하려 해서는 안된다는 것이다.


흔히 리더쉽을 이야기하면 많은 사람들이 카리스마, 친화력 등 단순히 인간관계에서 한 사람을 돋보이게 하는 능력들을 이야기하지만 사실 그런 능력은 조직을 이끄는데 있어 양념의 역할은 할 수 있으나 그런 리더쉽은 대다수의 조직에서 조직을 제대로 이끌어 성과를 내는데는 큰 도움이 되지 못한다는 사실을 간과한다.


팀장이 카리스마가 있다고 팀원들이 더 열심히 일한다는 것은 아무런 근거도 없고 사실도 아니다. 다만 조직력이 잘 갖추어진 조직에서 팀장이 카리스마가 있다면 팀의 규율을 다지는데 도움이 될 수는 있다. 또한 팀장이 친화력이 좋다고 팀원들이 열심히 일하는가? 팀장의 친화력은 그저 팀의 수직적 커뮤니케이션을 원할하게 하는데 도움을 줄 뿐이다.




하지만 어떤 조직이든 리더가 갖추어야 하는 공통의 덕목 혹은 능력은 분명히 있다. 20년의 조직생활에서 깨달은 몇가지 리더의 조건에 대해 써보고자 한다.


솔선수범(率先垂範)


너무 식상한가? 이 네 글자를 보고 "겨우 이 이야기를 하려고.."라는 느낌이 찰라의 순간이라도 들었다면 당신은 지금까지 리더의 자격이 없었다고 단언하여 말해주고 싶다. "맞아..!!"라고 무릎을 쳤어야 한다. 율곡선생이 왕에게 "솔선수범"할 것을 직언했을 만큼 솔선수범은 리더가 갖추어야할 첫 번째 덕목이다.


직원들에게는 회사가 어렵다며 비용절감을 외치고 업무 수행에 필요한 최소한의 업무추진비 마저도 쓰지 못하도록 이런 저런 제약을 가하면서 사장이나 본부장, 팀장이 차량을 지급받고 직원들이 상상하기 힘들만큼 법인카드를 쓰고 다닌다면 직원들은 결코 회사에 애사심을 갖지 않는다. 당연히 조직의 성과도 기대할 수 없다.


또한 업무에 있어서도 솔선수범해야 한다. 예를 들어 직원들에게 출근시간을 지키도록 강요하면서 임원들이나 팀장들이 출근시간을 제대로 지키지 않는다면 누가 과연 업무에 충실하겠는가? 


또한 특정업무를 직원에게 시키기 전에 리더가 그 업무를 훌륭하게 해내는 것을 직원들에게 직접 보여줘야 한다.직원들은 자신들의 리더가 자신에게 할당한 업무를 훌륭하게 해낼 수 있다는 것을 믿을 때 그 업무에 보다 적극적으로 나선다. 리더가 그 업무를 완수하는 것을 본적이 없다면 직원들은 그 업무를 리더가 훌륭하게 완수할 수 있다고 생각하지 않는다. 즉, 업무를 대충해도 리더가 그 업무의 결과에 대해 제대로 판단할 수 없을 수도 있기에 적극적으로 업무를 수행하지 않는 것이다. 반면 리더가 그 업무를 완벽하게 수행해내는 것을 본 직원들은 최소한 리더가 수행한 만큼의 완성도를 추구하며 업무를 수행하게 된다. 리더가 수행하여 완수한 완성도가 직원들이 업무를 수행했을 때의 최소한의 기준이라고 각인하기 때문이다.

때문에 리더는 리더에게 속한 직원들이 보고 따라야하는 업무 수행의 목표가 되어야 한다.


나 또한 15년 동안 조직을 이끌면서 가장 신경을 썼던 대목이기도 하다.



적재적소(適材適所)

리더는 직원의 능력과 경험치에 따라 업무를 수행하기에 가장 적합한 직원에게 업무를 할당해야 한다. 많은 리더들이 제대로 갖추지 못한 능력 중 하나다. 리더가 갖추어야 하는 적재적소의 덕목은 직원의 업무수행 능력과 업무 난이도의 균형을 맞춰 능력을 낭비하는 일이 없도록 하는 것이며 또한 업무에 문제를 야기하지 않도록 하는 능력이다.

너무 어려운 업무를 능력이 되지 않는 직원에게 할당하거나 쉬운 업무를 탁월한 능력을 가진 직원에게 할당하는 실수를 범하면 안된다. 


또한 직원들은 모두 각자의 장점과 단점을 갖고 있다. 조직에서 수행해야 하는 모든 업무에서 탁월한 능력을 발휘하는 직원은 없다고 생각해야 한다.(멀티플레이어는 없다.) 따라서 조직에서 수행하는 다양한 업무를 잘 수행할 수 있도록 직원들을 적재적소에 배치하는 능력은 리더가 갖추어야할 매우 중요한 덕목이다. 


영업적 능력이 떨어지는 직원에게 영업을 맞긴다든가 화술이 부족한 직원에게 프리세일즈 업무를 맞기고 직원들을 통솔하는 능력이 떨어지는 직원에게 특정 조직이나 프로젝트의 리더를 맏기는 등의 과오는 적재적소의 능력을 갖추지 못해 발생하는 문제다. 


자기에게 맞지 않는 옷을 입은것 같은 직원들은 당연히 저성과의 늪에 빠지게 되고 다른 직원들과의 업무적 관계에서 서로에게 불만을 갖게 되며 불평을 입에 달고 살게 된다. 이런 조직은 당연히 업무성과가 떨어질 수 밖에 없고 조직이 사분오열될 수 밖에 없다.


존중(尊重)과 공정(公正)

리더는 직원들을 인격적으로나 업무적으로 존중해야 한다. 그리고 공정해야 한다. 주변에서 흔히 직원들이 수행한 업무의 결과에 대해 너무 쉽게 소리지르고 꾸짓고 인격적으로 상처를 받을만큼 혼을내는 경우를 흔히 볼 수 있다. 그렇다고 제대로 코멘트를 해주는 것도 아니면서 말이다. 또한 사적인 친분이 쌓인 직원과 그렇지 못한 직원의 업무 결과에 대해 공정하지 못한 평가를 하기도 한다.


여러 직원이 함께하는 회의 시간에 친하다는 이유로 특정 직원에게 반말로 업무를 지시한다거나 직원들을 하인 부리듯 하며 무시하는 경우도 흔히 볼 수 있다. 둘 만의 공간에서 사적인 대화나 가벼운 업무상의 이야기를 할 때는 반말을 할 수도 있겠지만 여러 직원이 함께하는 공식적인 회의 석상에서 반말은 상황과 분위기를 봐가며 해야한다. 본인은 직원들을 존중하는 언행을 하고 있다고 생각하지만 막상 직원들은 존중받지 못하고 있으며 공정하지 못한 대우를 받고 있다고 느끼는 경우가 의외로 많다.


또한 직원에게 지시하여 작성된 보고서나 결과에 대한 검토 시 언성을 높이거나 (제대로 업무를 가르쳐주지도 않았으면서) 타박을 하는 행위는 결코 있어서는 안된다. 또한 그 결과물을 타박하고 처음부터 직접 다시 작성하거나 대대적으로 수정하는 행위 또한 피해야 한다. 이는 직원이 "그럴 거면 왜 시켰냐?" 라는 불만을 갖게되는 직접적인 원인이 되며 이후 다른 업무를 수행할 때도 "어차피 혼나고 다 고쳐질텐데..."라는 패배의식을 심어주게 된다. 번거롭더라도 함께 검토하며 수정 방향을 꼼꼼히 체크해주고 업무 담당자가 직접 수정하도록 하여야 하며 모두 완료되면 "칭찬"을 빼놓지 말아야 한다.


또한 주의해야 할 것은 "사적인" 일을 시키지 말아야 한다는 것이다.

쓰레기통을 비우게 한다든가 심부름을 시킨다던가 하는 행위는 삼가야 한다. 때로는 부탁을 통해 작은 일들을 시킬 수도 있겠지만 당위성은 항상 염두에 두어야 한다. 업무 외적인...사적인 일을 지시받고 수행하는 직원은 당연히 불만을 갖게 된다. "내가 심부름이나 하려고 이 회사에 입사했나?"라는 생각을 한번 쯤 안해본 사람은 없을 것이다. 그만큼 불만의 원인이 된다. 게다가 사적인 친분이 있다고 사적인 일을 시키거나 친하지 않은 직원에게 차별하는 듯한 업무를 맏기는 불공정은 최악의 리어가 되는 가장 빠른 지름길이다.


리더로 부터 존중받지 못하고 공정한 평가를 받지 못하는 직원들은 겉으로는 리더를 따르는 듯 보일 수 있지만 마음 속으로는 매우 강렬한 반감을 갖게 되며 조직의 다른 구성원과의 관계도 나빠질 수 밖에 없다.


공부(工夫)

내가 기술분야의 직업을 갖고 있기 때문인지는 모르겠지만 공부는 이 업종을 떠나는 순간까지 게을리해서는 안된다는 생각을 하게 되었다. 더군다나 작던 크던 기술조직의 리더라면 적어도 직원들보다는 많은 것을 알고 있어야 한다.


기술인력은 두가지 종류로 구분된다. 하나는 기술자이고 하나는 기능공이다. 넓은 의미에서 기술자는 기능공을 포함한다고 할 수 있다. 하지만 엄격히 따졌을 때 기술과 기능은 분명 구분이 가능하다.


특정업무에 숙련된..즉 반복되는 기술업무에 숙련된 사람은 기능공이라 불린다. 하지만 기술자라면 경험하지 못한 새로운 이슈에 대응할 수 있는 기반기술을 가진 사람을 뜻한다. 하지만 IT업종에서 많은 "엔지니어"라 불리는 사람들은 그저 "기능공" 수준을 벗어나지 못한다. 


나는 DBA나 DB엔지니어가 아니니까...

나는 개발자가 아니니까...

나는 네트워크 엔지니어가 아니니까...


적어도 기술조직의 리더가 되고자 한다면 DB, Network, OS, Programing은 물론 시스템SW에 대한 기반 기술들은 갖고 있어야 한다. 하지만 그 많은 분야의 지식을 쌓기위해서는 끊임없는 공부가 필요하다. 기술조직에서 그저 관리를 위한 리더는 존재가치가 없다. (적어도 난 그렇게 생각한다.)

하지만 기술조직의 팀장이나 부서장들 중에서 그렇게 열심히 공부하는 리더는 찾아보기 힘든게 현실이다. 오히려 사적인 이익을 취하기 위해 회사의 내부 정치나 인맥관리를 위해 술마시기를 즐기거나 자신은 잘 모르면서 직원들에게 떠넘기고 제대로 결과를 챙기지도 못하는 리더가 오히려 많은게 엄연한 현실이다.


그래서 조직원들이 따라 줄까? 과연 성과는 제대로 나올까? 그런 엔지니어들이 사업을 수행하는데 고객은 사업 수행 결과에 만족할까? 더군다나 변화 무쌍하고 새로운 기술이 넘쳐나는 IT 바닥에서 말이다.



지금까지 생각나는 대로 두서없이 리더의 조건에 대해 써봤다. 내 성격 상 한번 쓴 글은 오랫동안 다시 보지 않기에 읽기에 좀 거북한 표현이 있을지도 모르겠다. 20년간 일하면서 존경하고 따를 만한 리더를 만난적이 별로 없기에 세상의 많은 리더들에 대해 부정적인 생각을 갖고 있는게 사실이다. (하다못해 대통령 마저도 이모양이니...)


2016년 새해들어 복잡한 심경을 정리하며 문득 나는 어떤 리더였는지..그리고 내가 모셨던 리더들은 어떤 분들이었는지를 생각하다 문득 내가 추구하는 리더의 모습은 이런게 아닐까하는 생각이 떠올라 기록으로 남겨본다.



  • Frost. C 2016.01.07 15:22 신고

    솔선수범이야말로 가장 기본이 되지만 동시에 가장 어려운것이 아닐까 싶습니다ㅎㅎ 특히나 속칭 군대식 짬밥문화에 익숙한 사람들일수록 더 그런듯 하고요.. 꼭 찍어 관리자 입장에서만이 아니라 누구에게나 필요한것이 솔선수범이란 점을 상기하면서 새해 스타트를 잘 끊어볼까 합니다. 좋은 글 잘 읽고 갑니다~ 주인장님도 새해 복 많이 받으셔요ㅎ

    • taeho Tae-Ho 2016.01.08 08:45 신고

      감사합니다~ Frost.C님도 새해 복 많이 받으세요~

  • 2016.01.10 16:53

    비밀댓글입니다

    • taeho Tae-Ho 2016.01.10 22:02 신고

      방명록에 답변 드렸습니다. 새해 복 많이 받으세요.

  • 베짱이 2019.03.05 17:21 신고

    리더란, 겸손하고 또 겸손하고 마지막까지도 겸손해야하는 자리 같아요.
    갭이어(gap year)가 필요한 시대인 거 같습니다.

    • taeho Tae-Ho 2019.03.06 16:43 신고

      맞습니다. 더군다나 요즘은 신기술들이 많이 나오고 신세대일 수록 신기술에 빠르게 적응하니.. 예전 처럼 직급 높고 근무 경력이 많다고 기술이 뛰어난게 아니거든요. 그러다보니 겸손이 더 필요하죠.

  • [찌쏘]'s Magazine 2019.04.14 22:57 신고

    IT쪽 일이 쉽지가 않죠.. 저도 컴퓨터 전공자였다가 지금은 출자회사 관리 투자업무하는 쪽으로 전향되었는데.. 머 그런걸 떠나서 저도 13년차가되면서 느껴지는게 많습니다 ^^



ISMS인증제도와 ISMS인증심사원

ISMS인증제도는 기업 스스로 체계적인 정보보호 활동을 위한 관리체계가 수립되어 있는지, 그리고 관리체계가 수립되어 있다면 법적 요구사항 및 ISMS인증제도 자체의 기준을 충족하는지를 평가하고 수립되어 있는 정책, 지침에 따라 지속적인 정보보호활동을 하고 있는지를 평가하고 인증해주는 제도다.



그리고 ISMS인증심사원은 인증기준에 맞춰 정보보호관리체계를 운용하고 있는지 실사 및 평가를 수행하는 인력이다. ISMS인증심사원은 2013년 개정된 정보통신망 이용촉진 및 정보보호 등에 관한 법률과 이하 시행령 및 고시에서 그 자격에 대해 명시하고 있다.




"보"를 떼다.

인증심사원 자격을 취득하고 나면 심사 참여 경력이 없기 때문에 심사원(보)의 자격을 부여한다. "보"를 떼기 위해서는 심사 참여 4회 이상과 심사일수의 합 20일을 넘겨야 하는 두 가지 기준을 모두 충족해야 한다.

 

2015년 신설된 필기시험을 통과하여 인증심사원 자격을 취득하고 2016년 1월 말... 드디어 첫 인증심사에 참여하게 되었다. 모 시청의 사후심사로서 3일간 진행된 심사였다. 그리고 2016년 여름과 늦가을에 두번의 인증심사(각 4일과 5일)에 참여하였고 2017년 5월, 5일로 진행되는 심사(최초심사) 2회에 참여하여 심사참여 4회, 심사일수 20일의 조건을 모두 충족시킬 수 있었다.  



그 과정에서 아쉬운 점이 있었는데... 순수하게 실제 심사를 보고 배울 기회가 없이 바로 실무에 투입된다는 점이다. 심사에 참여하면 심사팀장은 인증기관(KISA, TTA, KAIT, 금융보안원)에서 담당하며 심사원은 KISA의 ISMS 홈페이지에 공고하여 모집한다. 그리고 심사팀이 구성되어 심사를 수행하게 되면 관리과정은 심사팀장이 담당하고 보호대책의 13개 분야를 나머지 팀원이 분할하여 심사를 수행하는 것이 일반적이다. 이 때 심사 경험이 있든 없든... 몇개 분야를 맡아서 심사를 진행해야 한다. 즉, 처음 심사를 나가는 심사원은 맨땅에 헤딩을 하는 상황이 발생한다.(물론 5일 간의 심사원 교육을 받기는 했지만....)  게다가 심사일정이 매우 빡빡하기 때문에 다른 심사원의 도움을 기대하는 것도 불가능하다. 때문에... 심사원(보) 때는 심사원 1명을 함께 보내 OJT 형태의 심사를 수행하도록 하는 것이 바람직하지 않을까 싶다.


어쨌든 "보"를 떼고 본격적인 인증심사 경험을 쌓기 위해 열심히 심사 참여 신청을 하고 있다.



  • 에스델 ♥ 2017.06.12 10:47 신고

    ISMS인증심사원에서 '보'를 떼신 것
    축하드립니다. ^^
    많은 경험을 쌓아서 멋진 활동 하시길 바라며...
    즐거운 월요일 보내세요!

    • taeho Tae-Ho 2017.06.12 12:51 신고

      감사합니다.. ^^ 손가락은 다 나으셨나 모르겠네요~~ 빨리 나으시길 바랍니다.

  • 카멜리온 2017.06.13 11:26 신고

    오 인증심사원(보)에서 조건을 충족하여 (보)를 떼셨군요!
    이제는 정식 심사원이 되신건가요? 축하드립니다~~
    바로 실무에 투입된다는 점이 조금 아쉽기는 하지만 바로 부딪혀보고 시행착오를 겪는 것도 좋을 것 같아요.
    한 분야의 전문가들도 처음에는 다 초심자였으니까요.

    • taeho Tae-Ho 2017.06.14 15:52 신고

      심사원(보)도 정식 심사원이구요. 다만 심사 경력에 따라 구분하는 것 뿐입니다.
      옳으신 말씀입니다~ 그래서 요즘 심사 열심히 신청해서 다니고 있습니다. ^^

  • 베짱이 2017.06.24 08:35 신고

    축하드려요. ㅋㅋ
    이거 무지 어려운거 아닌가요?

    • taeho Tae-Ho 2017.06.24 13:04 신고

      그정도는 아니구요... ^^ 멋도모르고 시험쳤다 운좋게 합격했죠..


로그 수집 이슈

서버 HW, 운영체제 그리고 서버에서 실행되는 웹 서버 등의 애플리케이션의 상태와 해킹 시도 등을 탐지하기 위해 각종 로그를 수집하는 것은 서비스 상태의 모니터링과 보안관제 등의 업무에서 필수적인 요소다.

그래서 ESM(Enterprise Security Management) 솔루션은 물론이고 SIEM과 보안관제 등의 솔루션에서 서버에 쌓이는 로그파일을 수집하는 기능을 제공하며 로그를 수집하기 위해 Syslog 를 이용하는 등 다양한 방법을 사용할 수 있다. 하지만 syslog나 snmp 등을 지원하지 않는 웹서버 로그나 DB로그 그리고 인하우스 애플리케이션의 로그는 별도로 프로그램을 개발하거나 유료SW를 설치하지 않으면 수집하지 못하는 경우가 많다.


특히나 로그를 수집하는 로그 수집 및 분석 솔루션들은 돈을 더~ 벌기위해 로그를 수집하는 간단한 프로그램을 유료로 판매하는 경우가 많다. 하지만 대부분 FTP나 SFTP를 통해 지정된 로그파일을 다운로드 받을 수 있는 기능을 제공하는 경우가 많은데 이 때 사용할 수 있는 간단한 로그 수집 스크립트를 Perl로 작성해보았다.


로그 수집 스크립트를 작성할 때 고려해야할 점은 몇가지가 있는데....


  • 증분 수집이 가능할 것. 
  • 로그 로테이션에 대응 가능할 것.
  • 읽어야할 로그파일이 존재하지 않거나 접근 권한이 없을 경우 에러에 대비할 것 
  • 로그파일의 용량이 클 경우 성능 문제 해결


이정도는 기본적으로 대비하여야 한다



로그의 증분 수집

아마도 많은 분들이 "증분 백업" 이라는 말을 들어보았을 것이다. 특정 시점에 데이터를 백업한 뒤 해당 시점 이후에 쌓인 데이터만 백업하는 것을 "증분 백업"이라고 한다. 로그를 수집할 때도 마찬가지 요건이 지켜져야 한다. 로그파일은 특정 시점 혹은 특정 용량에 도달할 때 까지 하나의 파일에 계속 추가 기록된다. 만약 한번 로그파일을 읽어간 뒤 일정 시간 뒤 다시 전체를 읽어가면 로그 수집 및 분석 솔루션 입장에서는 동일한 로그를 두번 읽어가는 현상이 발생하게 된다.


따라서 로그를 한번 읽어가면 어디까지 읽었는지를 기억했다가 다음번에 로그를 읽을 때 그 이후의 로그만 읽어가야 한다. 이러한 요건이 로그의 증분 수집 요건이다.


로그 로테이션의 대응

로그를 기록하는 거의 모든 SW나 장비들은 로그를 기록하며 일정 기간 혹은 일정 용량에 도달하면 로그파일을 다른 이름으로 변경하고 새로운 로그파일을 생성하여 기록한다. 이때는 이전에 읽었던 로그파일의 위치는 의미가 없어지게 되며 새로운 로그파일의 첫번째 로그부터 모두 읽어가야 한다.


로그 수집 스크립트는 이러한 상황에 대응이 되어야 한다.


로그파일 접근 에러에 대비

읽어야할 로그파일이 없거나 로그파일에 접근 권한이 없을 경우 에러가 발생할 수 있으며 이러한 상황에 대비할 수 있도록 코드가 짜여져야 한다.


로그파일의 용량이 클 경우 성능 문제 해결

읽어야할 로그파일이 클 경우 로그파일을 오픈한 뒤 이전에 마지막으로 읽어간 로그의 행을 찾아가는 과정에서 CPU 사용율이 증가하고 시스템이 느려지는 문제가 발생할 수 있다. 로그파일의 크기가 작을 경우는 전혀 문제가 되지 않지만 로그파일이 커질 수록 CPU 사용율은 점점 높아져 시스템에 문제를 야기할 수 있다.



로그파일 수집 스크립트의 작성

위의 로그파일 수집 이슈에 대응할 수 있는 스크립트를 만드는 방법은 매우 다양하다. 순수하게 Shell Script로 작성할 수도 있고 폼나게 C언어로 작성할 수도 있다. 하지만 현실적으로 가장 효과적인 방법은 Perl이나 Python 등을 이용해 스크립트를 작성하는 방법이다. 


여기서는 Perl을 이용해 작성하였다.


작성된 스크립트는 다음과 같다. 설명도 함께 달아두었다.


----------------------------------------------------------------


#!/usr/bin/perl

use strict;

use warnings;


my $CFGFILE = "CFG파일의 경로";

my $RFILE = "";

my $DFILE = "";

my $DSTDIR = "";

my $FILESFILE = "";

my ($rFile, $dFile, $cfgFile);

my $line;

my $ct = 0;

my $lct = 0;

my @tmpArr;

my @tmpStr;

my $strFile;

my (@srcFileName, @srcFileLine, @srcSvcName);


# CFG 파일을 연다.

open(cfgFile, "<$CFGFILE") or die("ERROR : Could not open logmon.cfg.");

while ($line = <cfgFile>) {

        if ( substr($line,0,1) ne "#") {

@tmpArr = split (':', $line);

# 읽은 파일을 저장할 경로

if ($tmpArr[0] eq "DSTDIR") {

  $DSTDIR = $tmpArr[1];

# 읽을 파일의 목록이 담긴 파일명 및 경로

} elsif ($tmpArr[0] eq "FILESFILE") {

  $FILESFILE = $tmpArr[1];

}

}

}

@tmpArr = ();


close(cfgFile);


# 읽을 파일의 목록이 담긴 파일을 연다.

open(cfgFile, "<$FILESFILE") or die("ERROR : Could not open files.cfg.");


while ($line = <cfgFile>) {


        if ( substr($line,0,1) ne "#") {


@tmpArr = split(':', $line);

# 읽을파일명:서비스명|현재까지읽은라인번호

                $srcFileName[$ct] = $tmpArr[0];

$srcSvcName[$ct] = $tmpArr[1];

$srcFileLine[$ct] = $tmpArr[2];


                $ct = $ct + 1;

        }

@tmpArr = ();

}

close(cfgFile);


# 현재날자와 시간을 구함. DSTDIR에 쓸 때 파일명에 날짜시간을 붙임.

my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime;

my $now = sprintf("%04d%02d%02d_%02d%02d%02d", $year + 1900, $mon + 1, $mday, $hour, $min, $sec);


$ct = 0;

$lct = 0;

chomp $DSTDIR;

chomp $FILESFILE;


# 읽을 파일명을 차례대로 루핑

foreach $RFILE ( 0..$#srcFileName ) {


  # 파일경로및파일명에서 파일명만 추출함.

@tmpArr = split('/', $srcFileName[$RFILE]);

  # 추출한 로그를 쓸 파일명을 기록

$DFILE=$DSTDIR . "/" . $tmpArr[$#tmpArr] . "_" . $srcSvcName[$RFILE] . "_$now";


  # 파일이 없으면 에러 처리

if ( -f $srcFileName[$RFILE] ) {

    # 읽을 파일의 현재 전체 라인수를 구함

$lct = `wc -l $srcFileName[$RFILE] | awk '{print \$1}'`;

    # 전체라인수에서 이전까지 읽은 라인수를 뺌. 즉 추출해야하는 라인수(끝에서 부터)

        $ct = $lct - $srcFileLine[$RFILE];


# tail 명령의 조합.

        $strFile = "tail -" . $ct . " " . $srcFileName[$RFILE];


     # 읽어야할 라인이 있으면...

        if ( $ct > 0 ) {

                $strFile = "tail -" . $ct . " " . $srcFileName[$RFILE];

                `$strFile >> $DFILE`;

# 파일 로테이션 되었으면 

} elsif ( $ct < 0 ) {

                $lct =~ s/\n//g;

                $strFile = "tail -" . $lct . " " . $srcFileName[$RFILE];

                `$strFile >> $DFILE`;

}

} else {

$lct = "0";

        }

 

chomp $lct;

  # 읽어야할 파일목록에 현재까지 읽은 라인 수 기록

open($cfgFile, ">>$FILESFILE.new") or die("ERROR : Could not open file - $FILESFILE.new -.");

        print $cfgFile "$srcFileName[$RFILE]:$srcSvcName[$RFILE]:$lct\n";

        close($cfgFile);


}

# 새로운 읽어야할 파일목록이 저장된 파일교체 (읽은 행수 반영) 

unlink $FILESFILE;

rename "$FILESFILE.new" , $FILESFILE;


---------------------------------------------------------------------------


이렇게 작성된 스크립트는 Crontab 에 등록하여 5분 간격 혹은 그 이상의 주기로 정기적으로 실행하도록 하면 된다.



데이터가 잔뜩~ 들어있는 엑셀 시트를 이용하다 보면 셀을 병합해야할 때가 있죠. 그럴 때마다 병합할 셀을 영역으로 선택하고 셀서식 페이지를 열고 맞춤 탭을 선택한 뒤 셀병합을 체크하는 작업은 한마디로 "노가다" 입니다. 병합해야하는 셀이 몇개 안되면 모르지만 수천라인에 있는 여기저기 흩어져 있는 수백개의 셀을 병합하는 것은 노가다 중에서도 고된 노가다죠. 


마침 방화벽 정책을 마이그레이션 하는 과정에서 기존의 정책을 이관시키고 관련 정책 문서를 만들어줘야 하는 상황이 생겼는데 기존 정책을 엑셀로 받아 Copy/Paste 방식으로 통합하다 보니 단위 정책들이 있는 셀을 병합해야 했습니다. 이 노가다를 팀원이 해야하는 상황이라 매크로를 만들기로 하고 인터넷을 뒤졌습니다.


그런데 인터넷을 뒤져보면 셀병합을 하는 매크로와 셀병합 시 사라지는 데이터를 유지하는 매크로는 있지만 아래 사진처럼 여러개의 열을 한꺼번에 처리하는 매크로는 찾을 수 없었습니다. 


병합 전병합 전


병합 후병합 후


이럴 경우 보통은 병합 작업을 세번 반복해야 하는 어려움이 있습니다. 이런 병합을 한번에 해내는 매크로 입니다.



다중 병합 매크로셀의 다중 병합 매크로


다중 for 문과 if 문을 알고 배열처리에 대한 개념이 있는 분이라면 이 매크로를 이해하는 것은 그리 어렵지 않습니다. 다만 Range로 선택된 각 열의 첫번째 셀의 값이 사라지는 문제가 있어서 한시간 정도 싸움(?)을 했습니다. 그 원인은 rStr 변수를 초기화하는 과정에서 rStr = "" 과 같이 초기화할 경우 엑셀에서 병합되는 첫번째 셀의 데이터를 제대로 표시하지 못하는 문제가 있기 때문인 듯 했습니다.


그래서 rStr 변수를 초기화할 때 각 열의 첫번째 셀의 값으로 초기화해주니 잘 수행이 되었습니다. ( rStr = cRng.Cells(1,t) 부분) 


위의 매크로는 아래 화면처럼 C4 에서부터 E8 까지 선택하면 각 열 기준으로 행의 병합을 반복 수행해줍니다. 




셀병합의 노가다로 고생하는 많은 분들에게 도움이 되면 좋겠네요.


주의!  행 전체를 선택하여 영역을 지정하면 무한루프에 빠질 우려가 있으니 반드시 사각형 영역 선택을 하시기 바랍니다.

        그리고 매크로에 대한 자세한 설명은 생략합니다.




2016년 7월 21일 오전...

지난 6월의 후반부 2주...그리고 7월 첫주의 토요일까지 5일간 이수한 개인정보영향평가 전문교육과 마지막날 치러진 평가시험의 결과가 어제 아침... 이메일로 송부되어 왔다.



그리고 함께 수신된 인증서...



이 개인정보영향평가에 대한 자세한 정보는 행정자치부에서 운영하는 "개인정보보호 종합포털"에서 확인할 수 있는데 개인정보 영향평가를 받고자 하는 기관은 반드시 개인정보 영향평가 전문교육을 이수하고 인증시험을 통과한 전문인력으로 구성된 영향평가팀에게 영향평가를 받도록 법제화되어 있다.


때문에 요즘(2016년)은 이 PIA자격증만 있으면 개인정보 영향평가 기관으로 지정받은 전문업체나 보안컨설팅업체에 어렵지 않게 취업이 가능하다고 하는 핫한 직종이다.


자세한 개인정보 영향평가 전문교육과 시험 내용은 카페에 올렸다. (보러가기)




2년 전... 전자정부 정보보호 솔루션페어 참가 이후 행사 참여는 일절 없었는데 2년 만에 작지만 포럼에 참가하게 되었다. 내가 하는 "서버보안" 일이 보안업계에서도 그다지 겉으로 드러나지 않는 분야이기에 세미나나 포럼 등 참가할 일이 사실 거의 없다.


서버보안은 많은 사람들이 그저 "운영체제의 보안 설정 잘해주면 되는거 아냐?"라고 생각하기 일쑤다. 하지만 운영체제의 보안설정이라는 것이 운영체제가 갖고 있는 근본적인 취약성을 제거해주지는 못할 뿐더러 "내부통제" 측면에서 봤을 때는 사실상 "보안 설정을 하나 안하나" 별반 차이없는 수준이기에 서버보안SW는 꼭 필요한 존재라 할 수 있다.


그리고 최근 이슈가 되고 있는 ISMS(정보보호관리체계) 인증 의무 대상 기업 확대에 종합병원 급의 대형 병원들이 무더기로 포함될 것으로 보이면서 매년 2회씩 진행되는 병원협회의 의료정보화 발전 포럼에서 이번엔 ISMS와 관련된 내용들이 많이 포함되어 있었다. 그리고 실제로도 대형병원의 정보시스템 부서와 보안 담당자 분들이 대거 참여할 것으로 예상되었고 실제도로 많은 분들이 관심을 갖고 참여하였다.



이번 포럼에서 우리회사는 "서버보안시스템 소개" 세션의 발표와 전시부스 운영을 맡아 진행하였다.


전시부스 사진... 사실 전시부스는 세개업체에서만 참여하였다. 포럼이 열린 연세세브란스병원 은명대강당의 구조상 그 이상의 부스는 설치가 어려워보였다. SecureOS인 RedCastle과 이중인증 그리고 명령어 통제 워크플로를 지원하는 AuthCastle과 통합감사서버인 AuditCastle.. 이 세개의 솔루션이 서버보안 시스템을 구성한다. 그 어떤 솔루션보다 "서버의 보안 접근 통제 및 내부통제강화"에 막강한 능력을 발휘한다. 그래서 내가 10년 넘게 서버보안 분야에 몸담고 있을 수 있다.



2016 병원 의료정보화 발전 포럼의 프로그램.. 오후 2시40분.. 한참 식곤증이 밀려올 타이밍.. 서버보안시스템 소개 세션이 있었다. 오전엔 이번 포럼의 핵심 주제인 보안과 ISMS 인증관련 세션들로 가득차 있다.



서버보안시스템 소개를 비롯해 하루종일 발표가 이어진 은명대강당.. 서버보안시스템 소개 세션 장면.. 홍성훈 차장이 찍어준 사진.. 교육, 제안발표, 설명회 등을 통해 자주 발표를 하지만 할 때마다 떨린다는.. -.- 이놈의 무대 울렁증은 사라질 줄을 모른다.



아래는 발표자료의 핵심 내용 중 하나인 "서버보안시스템"과 ISMS 인증기준의 관계를 정리한 장표..



사실 아직도 많은 기관과 기업에서 ISMS 인증기준 대비 제대로 된 보호대책을 수립하지 못하고 있는 것이 현실이다. 수립하고 있더라도 관리자 수준에서 모두 무력화 시킬 수 있는.. 서버보안 분야에서 일하고 있는 내 기준에선 내부통제 관점에서 볼 때 제대로 된 보호대책이라 인정하기 힘든 수준에 머무르고 있는 경우가 대부분 이다. 서버의 보안을 강화하기 위해선 서버 내에 강력한 통제 기능을 가진 서버보안SW가 필수적인 이유다. 게이트웨이 형태의 보안장비를 도입해서 해결할 수는 없는 것이 바로 "서버의 보안 강화" 숙제다.



2014년 겨울...


10년 여의 보안업계 근무 경력을 증거할 무언가를 만들기 위해...그리고 혹시나 모를 이직에 대비하기 위해 필기와 실기를 합쳐 평균 10% 내외라는 합격율을 자랑(?)하는 정보보안기사 자격증을 취득했다.


그리고 강화된 ISMS 인증심사원 제도가 시행된 첫 해인 2015년, 서류전형 및 필기시험과 5일간의 교육 그리고 실기 시험을 거쳐 자격증을 취득하게 되었다. (ISMS 인증심사원 필기시험과 심사원 교육 후기)


ISMS 인증심사원 제도

ISMS 인증심사원은 2014년 까지는 "위촉"의 형태였다. 위촉의 사전적 의미는 다음과 같다.


일반적인 의미는 어떠한 일을 부탁하여 맡긴다는 뜻이며, 법률적 개념으로서는 사무의 처리를 타인에게 의뢰한다는 뜻으로 위탁(委託)과 같다.


즉 한국인터넷진흥원(KISA)에서 심사를 대행할 심사원을 모집하여 교육과 시험을 거쳐 통과된 사람에게 심사를 대신 위탁하는 것이다. 그래서 ISMS 인증심사원들에겐 "자격증"이 아닌 "위촉장"이 주어졌다고 한다. (자격증이라 명시되었지만 실제론 위촉장이었다고 함)


하지만 2013년 개정된 정보통신망 이용촉진 및 정보보호 등에 관한 법률과 이하 시행령 및 고시에서 다음과 같이 인증심사원의 자격 요건을 명시하고 있다.



그리고 2014년 하반기까지는 별도의 시험없이 서류심사만으로 인증심사원 교육 대상자를 선발하여 교육을 실시하고 실기시험을 거쳐 인증심사원으로 위촉하였다. 하지만 지속적으로 인증심사에 대한 여러가지 문제점이 대두되자 2015년 부터 서류심사-필기시험-교육-실기시험의 4단계 전형을 실시하는 것으로 제도가 변경되었다.



제도가 변경되면서 2015년에는 필기시험이 치러졌으며 심사원도 "위촉"이 아닌 "국가 공인 자격"으로 인정받게 되었다. 그리고 합격율이 역시나 10% 정도 였던 2015년 필기시험에 운이 좋았는지 합격하고 교육을 거쳐 실기 시험을 치른뒤 ISMS 인증심사원 자격을 취득한 첫 기수(?) 되었다.




직장에 적을 두고 일을한지 20여년... 이제 앞으로의 20년(?)을 위한 전환점이 되지 않았나 싶다.


개발..DBMS..시스템(서버위주) 성능/장애/이벤트 통합관리..그리고 보안... 다양한 기술업무를 주 업무로 수행한지 15년.. 그리고 최근 몇년간은 프리세일즈 업무를 수행했다. 


지난 2~3년간 현재하고 있는 일 보다 한단계 발전적인 일을하기 위한 여러 시도를 했었고 그 마지막 결실의 수확을 눈앞에 두고 있다.


바로 ISMS 인증심사원 이다.


내가 작년부터 시도한 보안관리체계의 인증심사원 자격취득.. 작년(2014년)까지만 해도 ISMS 인증심사원 선발은 서류심사와 5일간의 심사방법론 교육과 교육 마지막날 치러지는 심사실습시험으로 이루어졌었다. 당연히 학벌.. 수행하는 업무가 보안컨설팅인지..등이 더 중요하게 서류전형에 작용했을거라 예상된다. 하지만 올해(2015년) 부터는 서류 자격 심사는 많이 완화되는 대신 필기시험이 치러졌다.


인증심사원의 자질논란 촉발

ISMS 인증심사원 선발과정에 필기시험이 추가된 이유는 현재 ISMS 인증심사를 수행하는 심사원들의 자질 논란 때문이라고 한다. 당연히 그런 논란이 발생할 수 밖에 없을 것이다.


보안관리체계의 핵심 요소 중 하나인 다양한 보안 솔루션을 조직의 보안정책에 맞추어 제대로 활용하고 있는지..그리고 관련 감사자료를 증적하고 있는지를 보는 것이 심사의 중요한 포인트 중 하나다. 하지만 현재 대부분의 기업과 공공기관에서 도입하여 운용하고 있는 보안 솔루션들은 자체적인 문제점을 매우 많이 갖고 있어 완벽하지 못한 상태로 운영되고 있는 경우가 많다.


반면 다양한 운영체제와 보안 솔루션들에 대한 기술적 이해와 경험이 없는 심사원들이 심사를 수행하고 있는 경우가 있다. 따라서 기업과 보안조직이 당면하고 있는 어려움을 이해하지 못한 채 무리하게 "원칙"만을 내세우면 심사 대상 기업에서는 "불만"을 토로할 수 밖에  없다. (ISMS/PIPL 등 대부분의 인증심사원이 서류전형과 교육만으로 심사원자격을 부여받고 있다.)   그러한 어려움을 이해하고 대체 가능한 보안정책과 보완대책을 인정하고 보완대책이 현실적인 대안이 될 수있는지를 봐주어야 하는데 현실적으로 경험이 부족한 심사원들은 그러한 유연성을 발휘하지 못하는 것이 아닐까 생각된다. (개인의견임)



인증심사원 필기시험으로 본 심사원 선발 기준

2015년 인증심사원에 지원하면서 작년(2014년)에 취득한 정보보안기사 자격증이 얼마간 도움이 되었다고 생각되며 2015년 1회 ISMS 인증심사원 필기 시험을 치른 경험을 바탕으로 보면...


1. 빠른 판단력과 이해력


시험의 형식을 보면... A4 사이즈 50 page에 육박하는 방대한 내용의 시험지가 주어진다. 문제는 단 80문제. 시간은 겨우 2시간이다. 지문과 예문 등을 꼼곰히 읽으며 생각할 시간은 없다. 누군가 그랬듯이 "동물적인 감각"으로 정답을 찾아내야 한다. 문제는 5지선다형이 대부분이고 정답 하나만 찾는 문제와 옳은 것 모두, 틀린것 모두를 찾는 문제도 출제된다.

아마도 길어야 5일인 심사기간에서 빠른 판단력과 이해력은 필수라고 생각한 듯 하다.


2. 풍부한 경험


문제를 풀다 보면 피 심사기관에서 발생할 수 있는 보안관련 이슈들이 제시해준다. 보안과련 이슈가 발견되었을 때 보안 홀은 맞지만 실제 업무를 수행하다보면 어쩔 수 없는 상황이 있게 마련이다. 이 "어쩔 수 없는"상황을 이해가고 있는지가 중요하다. 이 "어쩔 수 없는 상황" 임에도 불구하고 결함으로 지적해야 하는지, 보완대책이 있다면 PASS할 것인지를 판단해야 한다. 실무 경험이 없다면 "왜 어쩔 수 없는지"를 이해하지 못할 수 밖에 없다. 게다가 위험관리 프로세스에 대한 지식과 실무경험도 꼭 필요하다.


3. 보안 기술 지식


시험엔 일부 기술적인 지식을 묻는 문제도 출제된다. 정보보안기사와 비슷한 수준이거나 혹은 더 난이도 있는 문제도 있었다. 


제1회 ISMS 인증심사원 시험은 2015년 9월에 치러졌고 내년 부터는 초여름인 6월경에 치러질 것으로 보인다. 이 시험의 합격율은 정보보안기사와 마찬가지로 매우 낮은 편이다. 


제1회 시험에는 약 700명이 응시했다. (수험번호와 한곳 뿐인 시험장을 기준으로 추측하건대..)  그리고 합격자는 60명 내외다. (교육이 약 30명씩 2회로 나누어 진행됨) 즉 10%가 채 안되는 사람들만 합격하였다. 합격의 기준은 최소 60점 이상 그리고 필요인원 기준으로 위에서부터 짜른다고 한다.


ISMS 인증심사원 교육

필기시험에 합격하면 심사원교육을 받게 된다. 나도 겨우겨우 합격선에 들어 합격통보를 받았고 교육을 몇일 남겨둔 어제 이메일로 교육안내장을 받았다. 이메일로 날아온 교육 안내문의 커리큘럼은 다음과 같다.



교육내용은 매우 심플하다. 그냥 인증심사 실습이다. 그리고 마지막날엔 평가가 있다. 아직은 모르겠지만 작년까지의실기 시험의 합격율은 70%~80% 사이인 듯 하다. 구글링을 통해 검색해 보면 실제로 불합격한 사람의 수기도 있다. (무섭다....)


어찌됐든...이제 마지막 고비만 남았다.


마지막까지 힘을 내야겠다.


  • 지후대디 2015.10.25 12:47 신고

    목표를 위해 준비하시는 모습이 멋집니다. 해당분야도 점점 기업에도 보안이나 보안심사 받을 일들이 많아지니 앞날도 밝을듯 합니다 ^^

    • taeho Tae-Ho 2015.10.26 19:59 신고

      내년에 법이 개정되면 인증 의무대상기업이 대폭 늘어난다고 해서...
      사실 쫌 기대하고 있습니다. ^^


ISACA와의 인연

2002~3년 KBS에서 6개월 상주 프로젝트를 진행하던 즈음에 시험에 합격했던 CISA로 ISACA와 인연이 되었습니다... 그리고 몇년 뒤 경력 증명 자료와 함께 자격 신청을 했고 라이센스를 부여받았습니다. 그 후 몇년간은 미국 ISACA 회원으로 가입하여 CPE 입력과 회비 납부를 성실하게 수행하여 CISA 자격을 유지했었죠. 하지만 이직 한 직장에서 이직하지 않고 쭈욱~재직하면서 몇년동안 회비납부와 CPE 입력을 등한시 했더니.. CISA 라이센스가 Expire 되었습니다. 즉, CISA 자격이 취소 된 것이지요.


CISA 자격의 회복 방법

취소된 CISA 자격의 회복은 공식적으로는 불가능한 것으로 보입니다. ISACA 홈페이지에도 CPE 미등록 등 기타 사유로 CISA 자격이 취소되면 CISA 자격을 회복하기 위해서는 다시 시험을 치르고 합격한 뒤 경력을 증명해야 한다고 되어 있습니다. 하지만 "특별한 사유"로 CPE 등록이나 회비 납부가 불가하였다면 라이센스 담당자에게 이메일을 보내라고만 되어 있습니다.


정보시스템감사통제협회 저널 원고 초록제출과 기고문 선정 그리고 원고 편집/수정 과정

2015년 6월 한국ISACA의 회원에게 보내지는 저널 기고문 신청을 받는다는 메일이 눈에 띄었고 무엇에 홀리듯 신청을 했습니다. 초록까지 제출해달라 했는데 진짜 무엇에 홀리듯 초록을 작성해 보냈죠. 그리고 몇일 뒤 초록 검토를 마치고 원고를 7월초까지 제출해달라는 회신이 왔고 7월 4일인가에 1차 원고를 제출했습니다. 분량은 MS-Word 기준으로 약 7 페이지 분량이었습니다. 업무가 바쁘기에 몇일간 몰아치기로 작성하여 검토하고 제출했습니다. 평소 수행하는 업무의 연장선상에 있는 그런 수준의 일이었기에 빠르게 작성이 가능했습니다. 그리고 수정 요청이 오면 그때 조금 더 보완하자는 생각이었죠.


그리고 약 2주 뒤인 7월 중순경에 "특별기고"에 실을 수 있다는 연락과 함께 두 분의 검토 위원이 검토한 내용이 함께 왔습니다. 한분은 대폭 수정이 필요하며 전체적인 수준이 낮다...-.- 라는 평가였고 한분은 약간의 수정 후 게재해도 되겠다는...조금은 상반된 평가였습니다. 


낮게 평가하신 분은.... 저널지에 실리는 기고문도 양은 적지만 논문이라 표현하였고 비교적 높은 수준의 격식과 엄격한 문장 서술 기준 그리고 출처까지도 요구하고 있었습니다. 순간 "아...내가 너무 가볍게 생각했구나" 싶은 부끄러운 마음이 들었습니다. 그리고 한 분의 검토 위원은 비교적 너그럽게 몇가지 지적사항만을 제시하였습니다.


두 검토위원의 의견을 모두 반영하여 답변과 함께 2차 원고 제출을 하였습니다. 당연히 기한은 지켰습니다.


이후 다시 오타 및 문구 수정 요청이 있었습니다. 편집하시는 분들이 최대한 원고에 직접 손을 대지 않는다는 원칙을 지켤하는 것을 느낄 수 있었습니다. 그리하여 3차, 4차 수정 제출 후 9월 초 저널지에 최종적으로 실린다는 통보를 받았습니다.


그리고 9월 초, 정보시스템감사통제협회 저널 2015년 판을 보내주신다는 연락과 함께 배송 주소를 요청하여 알려드렸습니다. 


정보시스템감사통제협회(ISACA) 저널 2015 (통권 27호)

어제(2015년 9월 15일) 저널지를 수령했습니다.

꼼꼼하게 포장되어 있습니다.


총 5권이나 보내주셨습니다.


특별 기고란의 "서버 운영체제 접속에 대한 이중 인증 시스템 구축 사례 분석"입니다. 제 블로그에도 종종 관련있는 포스트를 올렸었습니다. 


본문입니다. 


여러차례 제품소개자료나 기술자료, 세미나 자료..그리고 교육교재나 프로젝트 산출물 등을 작성하고 책으로 제본하여 직접 작성한 글이 인쇄된 것을 본적이 있지만 저널지에 글을 실어보긴 처음인지라 무척 재미있는 경험이었습니다.


-- 관련 포스트 --

  1. [2 factor 인증] 공인인증서/OTP/ARS를 이용한 자연인 기반의 서버 접근제어(텔넷, SSH, FTP 등) 기법 2012/06/23
  2. APT 공격의 방어와 추적을 위한 보안 시스템 구성 2013/08/30
  3. 2 채널인증과 2 팩터 인증의 차이점과 네트워크 기반 서버접근제어 2 팩터 인증의 취약점 2014/03/15
  4. 금융감독원 전자금융감독규정에 서버 운영체제 계정 접속 시 2차 인증 의무화 시행되다. (2) 2014/07/17
  5. [서버보안] 서버 내에서의 명령어 통제 (실행) 기술 동향 (4) 2014/08/22
  6. 2차 인증 및 워크플로 기반 명령어 통제 시스템 2015/05/15



  • 에스델 ♥ 2015.09.17 10:32 신고

    우와~ 저널지에 글을 기고하셨군요^^
    수령한 저널지를 보니 멋있습니다.


평생교육이라는 말이 있 듯... 배움에는 나이가 없다고 한다. 하지만 이 명제는 누군가에게는 진실이고 누군가에게는 거짓이다. 술과 담배 그리고 유흥과 소위 여러 잡기에 찌들어 있는 많은 사람에게 평생공부라는 단어는 그리 어울리지 않는다. 많은 사람들이 공부보다는 인맥을 만들기에 몰두하고 있기에 무언가 새로운 학문과 기술을 배우는 것에는 소홀한 것이 현실이다. 그리고 우리나라에서는 새로운 학문과 기술보다는 "인맥"이 더 큰 투자 대비 효과를 보이는 것이 사실이고 대부분의 사람들이 그렇게 믿고 있다. 그래선지 기술분야에서 일하는 30중반 이후의 엔지니어나 개발자는 정체되어 있거나 퇴보하는 경우를 많이 볼 수 있다. 나이를 먹으면서 느는 것은 체중과 술 그리고 아집과 독선 뿐인 경우가 많은 이유다.


물론... 존경스러울 만큼 기술력과 컨설팅 능력을 키워나가는 엔지니어와 개발자도 있기는 하다.


나의 비전공 분야인 정보보안

기술적인 측면에서 정보보안은 컴퓨팅과 뗄레야  뗄 수 없다. 현대사회에서 90%이상의 정보는 컴퓨터 상에서 입력되고 저장되며 가공되고 보여진다. 따라서 디지털 전기/전자/통신공학과 컴퓨터사이언스 그리고 프로그래밍은 정보보안 전문가에겐 기반기술이다. 따라서 전자공학을 전공하면서 마이크로프로세서와 프로그래밍을 독학하다시피한 내게 정보보안의 최소한의 기초는 갖추고 있다고 본다.


흔히 보안이라고 하면 해킹, 리버싱 등과 같이 기술적으로 난이도가 높은 해킹기술만을 생각하는 사람들이 많지만 정보보안의 범주가 기술적, 관리적, 물리적 관점으로 구분되는 것에서 볼 수 있듯 조직(기업 및 공공부문)의 경영 및 관리와 법률적 관점에서 IT기술을 해석하고 적용할 수 있는 능력이 필요한 경우가 더 많다고 할 수 있다. 그러기 위해서는 기술적 지식에 정보보안에 필요한 관리적 보안 측면의 지식을 더 쌓아야 할 필요가 있다.


어떤 조직에서 정보보안이라는 과제를 수행하기 위해서는 기술적 관점에서의 해커와 엔지니어 그리고 관리적 측면에서의 컨설턴트 그리고 그 두분야를 모두 이해하며 코디네이션 해 줄 수 있는 정보보안전문가가 필요하다고 생각된다. 물론 그들 모두를 정보보안전문가라 부를 수도 있지만 내 생각에는 진정한 정보보안전문가는 특정 분야의 깊이 있는 지식보다는 IT분야의 폭넓은 지식을 갖고 있어야할 필요가 더 크다고 생각된다. (물론 다양한 기술에 대한 정확한 이해는 꼭 필요하다. 단순히 "들어봤다"거나 "대충 알고 있다"가 아닌 아키텍쳐, 네트워킹, 프로그래밍 관점에서 해당 기술에 대한 "이해"가 필요하다.)


그런 면에서 난 경영 및 법률을 포함하는 관리적 측면에서의 경험이 부족하기에 정보보안전문가라 부르기에는 미흡한 면이 많다고 생각된다.


그래서 선택한 고려사이버대학교 정보보안관리학과 편입 도전

2013년과 2014년엔 오랫만에 무언가 증거를 남길 수 있는 자기계발의 계획을 수립하고 하나의 목표를 이루었다. 5회까지 시행되었고 매 시험에서 최종 합격율이 10% 안팎인 정보보안기사 자격증을 취득한 것이다. 서버의 보안만을 다루던 내게 네트워크 보안, 애플리케이션 보안 그리고 정보보호법률과 컨설팅 영역인 위험관리에 대한 공부는 매우 새로운 지식들을 습득할 수 있는 기회가 되었고 공부를 하면서 많이 부족했었음을 느꼈다. 그리고 어쨌든 학원을 다니지 않고 독학으로 정보보안기사 시험을 준비해 자격증을 취득할 수 있었다. 하지만 내 스스로 돌이켜 봐도 역시나 정보보안 전문가라 칭하기에는 많은 부족함을 느낄 수 밖에 없는 과정이었다.


그래서 정보보안관리를 체계적으로 공부하기 위해 여러 사이버대학교의 정보보안 관련 학과를 살펴보았고 가장 인지도 있는 고려사이버대학교의 정보보안관리학과의 2015년 후기 편입에 응시했다.


고려사이버대학교의 후기 편입 응시 과정

내가 응시했던 고려사이버대학교의 2015년 후기 편입은 다음의 과정으로 진행되었다.


고려사이버대학교 후기 편입고려사이버대학교 후기 편입


가장 중요한 과정은 학업계획서 작성과 학업소양검사다. (그리고 원서 접수 후 최종졸업학교의 졸업증명서와 성적증명서를 등기우편으로 마감시한 내에 보내야 한다. 졸업증명서와 성적증명서는 이메일과 같은 온라인으로는 받지 않는다.)


고려사이버대학교 편입에서 응시자에 대한 평가는 학업계획서평가점수 70%와 학업소양검사 평가점수 30%로 이루어진다고 한다. 난 그걸 인지하지 못한 상태에서 학업소양검사에 회사 업무시간에 응시했다가 식겁했다. 중간에 끊고 다시 이어서 응시할 수 없기 때문이다. 일단 시작하면 끝까지 가야한다. 시간은 1시간을 주는데 최소 40분 이상 소비했었다. 업무중 응시하면 곤란한 상황이 발생할 수도 있으니 주의해야 한다.


반면 학업계획서는 마감일까지 수정이 가능하다. 학업계획서에는 자기소개와 학업계획 그리고 응시사유를 평가자를 설득할 수 있도록 체계적이고도 감동(?)을 줄 수 있는 내용으로 작성해야 한다. 물론 "거짓"을 쓰면 안되겠다. 흔히 자기소개서에 "거짓"을 쓴 것으로 보이는 입사지원자들을 너무도 쉽게 볼 수 있는데 그것은 본인의 "신용"을 깎아내리게 된다. 그리고 그러한 거짓은 한번 저지르게 되면 평생...반복해 저지르게 되는 중독성이 있다. 애초에 "거짓"을 쓰거나 말하지 않는 것이 중요하다.


고려사이버대학교 2015년 후기 모집의 경쟁률

응시하고 나서 결과를 기다리는데 경쟁률이 궁금해 찾아보고 깜짝 놀랄 수 밖에 없었다. 사이버대학교 후기 모집에 그렇게 많은 사람들이 응시하리라고는 생각하지 못했었다. 경쟁률이 10대1이 넘는다니...



내가 응시했던 3학년 일반전형 공학계열의 경쟁률이 12.3대1이었다. 아마도 정보보안관리학과는 학과의 특성상 더 높은 경쟁률을 보이지 않았을까 싶다.


응시 결과

높은 경쟁률에도 다행스럽게 합격할 수 있었다. 자기소개서와 소양검사결과가 뜻밖에도 꽤나 잘 나왔던 듯하다.


고려사이버대학교고려사이버대학교


이제 등록금 내고...

열심히 공부할 일만 남았다.

앞으로 2년간은 딴 생각하지 않고 학업에 전념해야할 듯 하다. 


그리고 그 다음엔 바로 "그 것"에 도전해 봐야겠지 ??



  • 지후대디 2015.07.19 21:07 신고

    도전에 박수를 보내드립니다. 저도 본 받아야 되는데 날이 갈수록 새로운 배움에 게을러 지는것 같습니다

    • taeho Tae-Ho 2015.07.20 10:27 신고

      박수까지~~ ^^ 감사합니다.
      지후대디님의 글솜씨야 말로 본받고 싶습니다. ^^


중소규모의 솔루션을 공급하는 IT 업체의 엔지니어들은 하루에도 두 개 이상의 프로젝트를 지원해야 하는 경우가 많다. 일 년 내내 그렇게 프로젝트를 지원하다 보면 프로젝트별로 작성된 산출물에 대한 관리가 무척 어렵다. 개인적으로는 노트북이나 외장하드에 고객사나 프로젝트 별로 폴더를 만들어 저장해 두는 경우가 대부분이다. 그리고 혼자 사용한다면 폴더에 의한 관리만 잘해도 크게 문제가 되지 않는다.


하지만 문제는 산출물의 공유에서 발생한다. 


산출물이나 기술자료의 공유를 위해 FTP서버나 게시판을 이용하는 경우가 많은데 이 또한 고객사나 프로젝트 혹은 문서내의 목차 등에 의한 검색에 한계를 갖는 경우가 대부분이다. 그래서 기술 지원 업무 관리 시스템을 재구축 하면서 그누보드5를 이용해 문서 관리를 위한 기능을 만들어 보기로 했다.


아래 화면이 그누보드의 스킨을 조금 수정하고 그누보드에서 지원하는 확장필드를 이용해 만든 문서 저장 게시판이다.


그누보드5의 리스트 스킨 수정



맨 위의 문서 종류는 그누보드에서 지원하는 식별자다. 아래 게시판의 글 목록에서 "제목" 대신 확장필드에 지정한 "고객사"와 "프로젝트"를 보여주도록 했다. 


그리고 아래의 검색창에도 "고객사명"과 "프로젝트명"을 이용해 검색할 수 있도록 했다. 그누보드에서 검색창에 확장필드의 값을 지정할 경우 자동으로 확장필드에서 검색하도록 편리하게 만들어져 있었다.


그누보드5 글쓰기 스킨에 확장 필드 값 입력하기

글쓰기 스킨에서 확장필드의 값을 입력하는 입력상자를 만들고 기술지원 관리시스템에서 등록한 프로젝트를 선택하여 입력할 수 있도록 그누보드5의 write.skin.php를 수정하였다.

아래 화면처럼 "찾기"버튼을 클릭하면 고객사/프로젝트 (단위업무) 선택 창이 뜨고 특정 단위업무(프로젝트)를 선택하면 입력이 된다.


아래 화면은 프로젝트가 선택되어진 화면이다.



등록된 산출물...


아키텍쳐 설계서가 등록되었고 "제목" 부분에 "고객사"와 "프로젝트명"이 표시되는 것을 볼 수 있다. 고객사와 프로젝트 명으로도 검색이 가능하다. 그누보드5에서 지원하는 구분자와 함께 사용하면 특정 프로젝트의 특정 산출물을 검색할 수 있겠다.



등록된 산출물 게시글의 내용을 보는 화면에도 고객사와 프로젝트명, 그리고 문서 종류를 함께 표시하도록 하였다.




산출물 관리에서 이렇게 도구를 만들어 제공하는 것 보다 더욱 중요한 것은 이 도구를 얼마나 효율적으로 사용하느냐다. 


문서의 작성자, 작성일, 버전은 물론...

문서를 등록할 때 등록자가 문서 내용의 목차,문서의 주요 내용 등을 함께 기재하여 검색의 효율을 높일 수 있도록 하는 것이 더욱 중요하다. 아무리 좋은 도구를 제공해도 사용자들이 등록된 문서를 제대로 검색해 볼 수 없다면 그 활용도는 매우 떨어질 수 밖에 없다.


다음에는...


위키를 이용한 문서 관리를 한번 연구해볼 필요가 있겠다. 위키에서도 수십..수백개의 고객사와 프로젝트 같은 키에 의한 문서 식별이 가능할까 모르겠다.


<추가 2015.03.18>

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


** 호스팅이 만료되어 폐쇄합니다. (2016/01/05) **



  • 2016.01.05 00:18

    비밀댓글입니다

    • taeho Tae-Ho 2016.01.05 09:45 신고

      안녕하세요. 뭐 검토하고 자시고할게 있나요? 저도 오픈소스가져다 고쳐서 쓰고 있는데..당연히 도움드려야죠..
      그런데 저도 전문개발자도 아니고 수정한지 1년이 다돼가는지라 기억을 더듬어 찾아야 하네요. ^^ 어떤 식으로 도움을 드려야할지 모르겠습니다. 블로그의 메일주소로 메일주시면 답신드리겠습니다.

  • 2016.01.05 22:25

    비밀댓글입니다


예전에 만들어 사용하던 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>

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



  • Orangeline 2015.01.13 14:23 신고

    일정관리 시스템 멋진것을 만드셨군요~
    요즘에 운영사 PM으로 개발사를 상대하다보니 이런 프로그램이 있어야 할것같다는 생각을 자주 합니다.
    하지만 10명이내 프로젝트라 도움이 될까도 생각해보게 되네요.

    • taeho Tae-Ho 2015.01.13 14:29 신고

      ㅎㅎ인원수가 적어도...일정관리와...업무수행내역 관리는 꼭 필요하죠..기록이 남지 않으면... 일하지 않은 것과 같다는게 제 원칙비스므리 한거라..

  • 지후대디 2015.01.15 23:21 신고

    저는 예전에 꽤 비싼 해외 제품을 국내에 맞게 커스트마이징 된 툴을 사용했었는데 그것만큼 기능이 좋아보입니다. 이런툴을 잘 이용해야 하는데 제가 일하는던 예전 직장에서는 개발쪽은 잘 이용하는데 더 필요해 보이는 영업쪽의 이용이 적어서 좀 아쉬움이 있엇습니다. 자체 개발하셔서 사용하시는거라면 돈 버신 겁니다. 사용료가 만만치 않았거든요 ^^

    • taeho Tae-Ho 2015.01.16 09:05 신고

      아이고..과찬이십니다...그저 제가 일하는 회사의 기술업무에 최적화? 되어 있는 거라서 범용으로 쓰기엔 부족한게 많습니다.
      프로젝트의 단계별 진행률을 간트차트로도 표현하고 싶은데...코딩실력이 딸려서 못하고 있기도하구요..


보안 쪽 일을 한지도 벌써 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회 필기에 합격하고 오랜 시간이 지나 겨우 실기 시험에 합격하였다. 오랜 시간 머리속을 지배하던 시험..시험..시험..의 강박에서 벗어나는 것이 시험의 합격 기쁨보다 더 큰 듯 하다.










  • 에스델 ♥ 2014.12.16 10:51 신고

    시험에 합격하시고~
    정보보안기사 자격증을 받게 되신 것
    축하드립니다.^^
    좋은 하루 보내세요!

    • taeho Tae-Ho 2014.12.17 10:42 신고

      감사합니다~ 즐거운 크리스마스 되시길 바랍니다. ^^

  • 지후대디 2014.12.16 17:57 신고

    큰 성취를 이루신것 축하드립니다 그나저나 실기 문제 수준이 허걱이군요 어려운 시험을 통과하신것 먼저 축하드립니다

    • taeho Tae-Ho 2014.12.16 18:01 신고

      감사합니다.. 너무 긴 시간이 걸려서 조금? 민망하기도 합니다.

  • 2014.12.29 20:00

    비밀댓글입니다

    • taeho Tae-Ho 2014.12.29 21:20 신고

      안녕하세요.. 합격하셨다니 축하드립니다..저도 턱걸이라.. ^^
      어떤 교육기관에서 수강하고 계신지는 모르겠지만 취업하시기도 전에 합격하셨다니 취업에 도움이 많이 되시겠네요..
      RedCastle은 체험판이 따로 있지는 않습니다. 개인 고객은 없고 모두 공공기관이나 기업이 고객이기 때문에 그렇습니다. 아마도 그래서 답이 없을 수도 있구요.. ^^
      RedCastle은 조달가 기준으로 논리적 서버 기준으로 300~400만원 정도 합니다. 조달이 아니라면 서버의 CPU(코어)개수 기준으로 견적이 나갑니다만 가격은 영업에게 문의를 하셔야 하구요.
      아마도 교육수강 중 프로젝트를 위해서라면 Tempapory License로 잠시 테스트하시는 것은 제 선에서 해드릴 수 있구요. 다만 교육을 받으셔야 사용이 가능하실 겁니다. 메일 주소를 비밀댓글로 달아주시면 제 메일주소를 보내드릴테니 어떤 프로젝트인지와 하고자 하시는 내용을 알려주시면 지원 가능 여부를 회신드리도록 하겠습니다.

  • 2014.12.30 18:15

    비밀댓글입니다


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


  • 지후대디 2014.10.24 21:46 신고

    강의를 하시다니 멋지십니다. 그렇다면 교육생들은 혹시 군인들인가요?
    궁금해집니다 ^^

    • taeho Tae-Ho 2014.10.24 23:32 신고

      네..군무원...장교...부사관 등 다양했습니다...^^;;

  • 쭈니러스 2014.10.26 10:17 신고

    좋은 지식들이 널리 전파될 수 있었으면 좋겠네요~
    잘 보고 갑니다~

  • Orangeline 2014.10.27 16:26 신고

    멋지십니다. 보안전문가라니!!
    3D 코더라 ㅜ.ㅜ

    • taeho Tae-Ho 2014.10.28 08:58 신고

      코딩도 보안에서 매우 중요한 포인트입니다~~~
      3D라뇨.. 개발은 IT의 기본입니다~~
      개발없이 IT가 존재할 수 없죠~

  • 하루10분 2014.11.01 15:46 신고

    보안전문가!! 멋있으세요 ㅎㅎ


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






  • 지후대디 2014.07.26 16:14 신고

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



새로운 포스트 (업그레이드 되었습니다.): 프로젝트 및 일정관리 시스템 리뉴얼 (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시간은 여기에 투자 해볼텐데... ^^




  • 쭈니러스 2014.05.14 21:02 신고

    일을 하다보면 좋은 도구가 필수인데~~~
    매우 유용하겠네요^^


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


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



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



그리고 몇일 뒤...

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



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

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



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



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






전에 기술지원조직의 업무관리에 필요한 간단한 프로젝트 및 일정관리 시스템 개발에 대한 포스트를 기록한 적이 있다. 그리고 시간은 흐르고 흘러 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 등이 그렇다. 대부분 이미 수행하고 있는 세부 단계들을 하나로 엮어 체계화한 것이 이런 표준 모델이다.

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

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




통합계정권한관리(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의 구축에 성공하는 기업은 얼마나 될지..자못 궁금하다.




  • yvette 2016.08.30 19:13 신고

    잘보고 갑니다. 지금은 어떻게 구축하고 계신지 너무 궁금합니다. ^^

    • taeho Tae-Ho 2016.09.01 11:04 신고

      계정관리(IM/IAM) 시장이 엉망이 되었습니다. ^^ 전문계정관리 솔루션이 아닌 제품들이 빈약한 계정관리 기능을 내세워 시장을 침범하고 있는 상황이죠. (시스템계정관리분야) 그래서 전 계정관리 쪽 일은 하지 않고 있습니다.
      댓글 감사드립니다~



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

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

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

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



  • 선길이형 2014.10.20 17:52 신고

    글에 진정성이 느껴지네요. 많은걸 느끼고 갑니다.

    • taeho Tae-Ho 2014.10.20 18:29 신고

      오랫만에 쓴 글을 보니...여기저기 오타도 보이네요.. 좋게 읽어 주시니 감사할 따름입니다.



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


나는 엔지니어다.

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

 

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

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

 

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

 

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

 

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

 

나는 그냥 엔지니어다.

 

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

 

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

 

로그인


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

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

 


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

 

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



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



기술지원현황조회



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

 

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

 

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

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



IT업계에 몸담고 수많은 BMT를 했지만 특별한 기억으로 남는 BMT는 그리 많지 않다. BMT에서 이겨 우선 협상 대상으로 선정되고도 경쟁제품인 리포트디자이너의 가격 후리기로 인해 포기했던 SKT NGM의 웹 리포팅 솔루션 BMT... 멀고먼 목포에서 2박3일로 실시됐던 삼호중공업의 서버통합관리솔루션 도입관련 BMT.. LG필립스LCD의 서버통합관리솔루션 도입 BMT...

최근에 실시된 BMT로는 이제 이야기를 시작할 서버보안S/W (Secure OS) 도입을 위한 금융결제원 BMT다...

전 직장인 포시에스에 근무할 때 인연을 맺었던 eTrust Access Control....

세계시장 No.1을 자랑하는 Secure OS이지만 국내에서는 여러가지 이유로 인해 점점 밀려나고 있다. 금융결제원도 처음에는 외산인 eTrust Access Control을 여러 업무의 서버에서 사용하였지만 2004년 쯤을 기점으로 더 이상 외산인 eTrust Access Control을 도입하고 있지 않다. 대신 안정화 단계에 접어든 국산 Secure OS를 도입하였고 2004년 당시 국산 제품중 가장 선도 업체였던 Secuve TOS를 도입하여 운용하였다.

하지만 2006년 11월... 금융결제원의 ISAC 팀과 VAN사업팀의 주도하에 표준 Secure OS 선정을 위한 작업을 진행하였고 웹서버의 웹페이지에 대한 접근 통제 정책을 적용한 뒤 실시한 웹 부하 테스트와 웹서버 및 웹 미들웨어의 버그를 가상한 해킹 테스트를 포함하는 BMT를 실시하여 당당히 금융결제원의 표준 Secure OS로 선정되기에 이르렀다.

BMT 준비를 위해 밤낮을 잊어가며 요구기능을 추가해준 연구소의 나은성 팀장님, 그리고 박진배 팀장님의 노력이 있었기에 금융결제원의 BMT를 성공적으로 수행하였고 경쟁제품(Secuve TOS, RedOwl)을 물리치고 이길 수 있었다.

그리고 그해 12월... 최초 10여대의 설치를 시작으로 계속적으로 금융결제원의 서버에 RedCastle이 설치되고 있다.

-----------------------------------------------------------------------------------

2007년 1월 25일[ 디지털타임즈]

- " 레드게이트 , 금융결제원 전산시스템 서버보안 솔루션 공급업체로 선정"

- 금융 ISAC 실 주관 BMT 를 통한 기술평가
- 향후 금융권의 서버보안 솔루션 도입 관련 성능평가를 위한 선도사례로 평가
- 국산 서버보안 솔루션의 외산 솔루션 대체를 통한 주류시장 진입 사례

서버보안 전문기업 레드게이트 ( 대표 김기현 , www.redgate.co.kr) 는 금융결제원의 전산시스템용 서버보안을 위해 자사의 서버보안솔루션 , ‘ 레드캐슬 ' 이 선정되었다고 1 월 23 일 밝혔다 .

이번 사업은 전자금융연구소 내의 금융 ISAC 실이 금융결제원의 전산시스템 특성에 최적화 된 서버보안 솔루션 선정을 위해 주관한 BMT 를 통해 기술평가가 이루어졌으며 ,
‘ 레드캐슬 ' 제품이 금융결제원이 제시한 서버보안 기능요구사항을 대부분 만족시키는 것은 물론 구현기술 중 스케줄링 방식을 통한 자동 무결성 점검 및 정책 별 위험등급 / 대응방법 지정 등의 경쟁사와는 차별화된 서버보안 기술 들이 이번 사업을 수주할 수 있었던 주요 이유였다고 전했다 .

레드게이트는 이번 금융결제원의 BMT를 통한 국산 서버보안 솔루션 도입이 그 동안 외산 제품 및 SI사업을 통한 제안 솔루션을 그대로 사용해 오던 금융권에서, 본격적으로 서버 보안 솔루션에 대한 성능 평가를 통해 도입을 추진하는 시발점이 될 것이며 이는 국산 서버보안 솔루션에 대한 공공기업 분야에서의 오랜 기간의 시장 검증이 완료되었고 이제 은행 , 증권 , 보험 , 카드 등의 금융기관과 민간기업이 주축이 되는 서버보안 솔루션의 주류시장이 개화되는 시기가 오고 있음을 의미한다고 했다 .

레드게이트 김 기현 대표는 “ 이번 BMT 를 통해 선정된 ‘ 레드캐슬 ' 제품이 금융결제원 내의 지속적인 서버보안 구축 사업을 위한 솔루션으로 공급될 것이며 , 금융 기관 들의 서버보안체계 구축을 위한 좋은 선도사례로 참조될 수 있을 것 ” 이라고 하며 향후 레드게이트의 금융권 시장에서의 활약상을 기대해 달라는 당부도 전했다 .

레드게이트는 지난 연말 전국 232 개 시 , 군 , 구와 행정자치부의 공통기반 시스템에 대한 서버보안 프로젝트를 무사히 완료했으며 최근에는 ING 생명의 전사 시스템 서버보안 프로젝트 사업을 수주하여 공급을 완료했다고 전했다 .

2007 년 1 월 23 일



내가 전산분야에 발을 들인것이 대학에 입학하면서 였다. 그리고 몇몇 자격증 취득을 위해 시험을 보곤 했다. 끈기있게 공부하지 못하고 중도에 포기한 것도 있지만  업무상 꼭 필요한 자격증 몇개는 끈질기게 공부(?)해서 취득한 것도 있다.

내가 갖고 있는 라이센스를 한번 정리해보려한다.

먼저 그 유명(?)한 CISA....라이센스..

시험은 2003년에 합격했지만 라이센스를 2006년에 신청했다..

단 한번의 필기시험으로 평균 75점(독특한 점수 체계를 가진 시험...) 이상 획득해야하고

이후 혹은 이전에 5년의 보안감사분야 및 개발 혹은 전산관리의 경험을 갖고 있어야 주어지는 자격증이다.

보안 관련 자격증으로 분리되지만 보안 분야는 시험 내용의 일부일 뿐인 자격증이다.

사용자 삽입 이미지


  • 선길이형 2014.10.20 17:54 신고

    덜덜 2008년의 글을 2014년이 되어 보게되었는데 여전히 그때 성취했을때의 감동을 간접 체험합니다.


1998년에 취득한 CA Unicenter 엔지니어 라이센스....

커트라인 80점인 1차 Basic과 2차 Advanced 시험을 통과해야만 주어지는 자격증이다.

한국CA와 몇몇 관련 엔지니어만 갖고 있는 자격증으로서 오픈북으로 진행되는 시험인 만큼

단순 암기보다는 실무 지식과 정확한 개념의 이해가 있어야만 패스할 수 있는 시험이다.

당시 이재철,이재헌,이훈 등 추억의 동료들과 함께 취득했다.

사용자 삽입 이미지



2002년 12월 부터 2003년 6월까지 진행한 마지막 Unicenter 프로젝트 였다. 이 기간중에 CISA 시험에도 합격했고 몇몇 유능하신 분들을 알게된 때이기도 하다. 넓은 이해심으로 많이 부족한 나에게 아무런 질책도 하지 않으셨던 고객사 박차장님.. 말썽쟁이 백대리.. 그리고 많은 의견충돌로 맘고생하셨을 김PM님...
 
마지막 Unicenter 프로젝트여서인지 자꾸 뒤돌아보게 한다.

-------------------------------------------------------------------------------------------------

== 시사 컴퓨터 ==

[Case Study - KBS 통합관제시스템]

KBS, CA 유니센터 기반 통합관제시스템 구축

방송사 최초로 ERP까지 통합관리 환경 갖춰

KBS는 유니센터를 활용해 크게 12개 부문에 걸친 통합관제시스템을 구축했다. 주요 단위 관리

부문은 통합관리, 장애관리, 성능관리, 애플리케이션 관리, SAP R/3 관리, DB 관리, 작업 프로

세스 관리, 원격 관리, 통계 분석 관리, 헬프데스크, 자산 운영관리와 이 모두를 통합 운영

관리할 수 있도록 하는 통합 관리 인터페이스 등이다. 이번 구축의 특징으로는 응용프로그램

관점에서의 시스템 통합 감시 및 서비스 수준 관리를 구현했으며, 국내 최초로 SAP R/3에

대한 통합 관리 환경을 구축했다는 것이다. 이와 함께 이메일, 휴대폰, PDA 등 다양한 사용자

환경에 적합한 이벤트와 자동 측정 결과의 자동 통보 및 원격 제어 환경을 구현한 것이다.

<이 상 기자 sanglee@sisait.co.kr>


사용자 삽입 이미지

프로젝트 구성도....


eTrust Access Control 기술지원 일을 할 때 취득한 CACES 라이센스. 사실 현재 별 도움은 되지 않고 있지만  서버보안의 기초를 다질 수 있는 기회였었다.

unicenter@네이버
---------------------------------------------------------------------------------------------------

e트러스트 엑세스 컨트롤 자격증 11명 취득
[디지털타임스 2003-05-13 03:00]
한국컴퓨터어쏘시에이트(www.ca.com/korea 대표 지일상)는 12일 자사 e트러스트 자격증을 취득한 11명의 `e트러스트 액세스 컨트롤 CACES(CA Certified eTrust Specialist)'에게 자격증 수여식을 가졌다.

이번 자격증 수여식은 지난 1월부터 3월까지 세 차례에 걸쳐 실시한 e트러스트 액세스 컨트롤 레벨1과 레벨2의 교육 및 테스트를 통과한 엔지니어를 대상으로 실시됐다. 취득자는 네비텍 김대성, 메이저텍 류해웅, 오픈데이타시스템 박정만ㆍ류동인, 한국전자증명원 장원근ㆍ이시종, 포시에스 ㅇㅇㅇㆍㄱㄱㄱ, 싸이버텍홀딩스 이정범ㆍ남동관, 대구오픈정보기술 배윤규 등 7개 채널 파트너의 11명이다.

CA의 e트러스트 자격증 시험은 레벨1과 2의 2단계로 분기별 1회씩 교육과 시험이 진행된다. 현재는 서버보안 솔루션인 `e트러스트 액세스 컨트롤'에 대해서만 실시되고 있으며, 단계적으로 싱글사인온, ID관리, 오딧, 폴리시 컴플라이언스 등 5개 분야로 확대해 나갈 계획이다.

자격증의 종류는 두 가지로, 1개의 제품에 대한 레벨 1과 2를 통과한 경우는 CACES(CA Certified eTrust Specialist), CACES를 최소한 3가지 이상 보유한 경우는 CACEE(CA Certified eTrust Expert)가 주어진다.

한민옥기자

한민옥 (mohan@dt.co.kr) 

사용자 삽입 이미지



포시에스 재직중에 Oz Report와 CA Unicenter를 연동하여 개발한 Oz for Unicenter의 CA Smart 인증.

당시 백대욱 대리가 미국 CA로 건너가 인증과정을 수행했고 이훈 대리와 내가 회사에서 밤샘을 했었다.
일부 웹 소스와 이미지를 수정하여 메일로 미국으로 보낼 때 파일을 빼먹고 압축하는 알집의 버그로 인해 황당한 고생도 했던 추억(?)이 새롭다.

unicenter@네이
---------------------------------------------------------------------------------------------------

포시에스, CA 스마트 인증 획득
[edaily 2003-10-21 11:39]
[edaily 이진우기자] 포시에스(056710)는 21일 미국법인이 포시에스의 웹리포팅 솔루션에 대해 CA사의 "CA스마트"인증을 받았다고 공정공시했다.

이하는 공정공시 전문이다.

- 유니센터용 웹 리포팅 솔루션 오즈를 통하여 다양한 보고서 제공- CA 본사와 공동 마케팅 및 영업 활동 전개 웹 리포팅 솔루션 전문업체 포시에스(대표 조종민, www.forcs.com)의 미국법인인 포시에스 인터내셔널이 미국 컴퓨터어쏘시에이트(Computer Associates International, CEO Sanjay Kumar, www.ca.com 이하 CA) 본사로부터 CA의 유니센터용 웹 리포팅 솔루션인 오즈 포 유니센터(OZ for Unicenter)가 "CA smart"인증을 부여 받았다고 20일 밝혔다. 이 제품은 CA의 시스템 관리 솔루션인 유니센터와 포시에스의 웹 리포팅 솔루션인 오즈 기술을 연동시킨 것으로, 금년 6월에 CA와 비즈니스 미팅을 진행하던 중 CA 유니센터 팀장이 먼저 ca smart 인증 취득을 요청하였고, 여러 테스트와 비즈니스 가능성을 점검하면서 인증을 취득하게 되었다. 대부분의 국내 기업들이 해외 기업과의 인증을 마케팅차원으로만 활용하고 있는 반면, 포시에스는 미국 CA 본사 솔루션팀과의 연계를 통해 비즈니스 가치를 양사가 먼저 확인하고, 진행된만큼 실질적인 비즈니스 창출에 기여할 것으로 기대하고 있다. 이번에 개발된 유니센터용 오즈는 유니센터의 실시간 모니터링 결과를 보고서로 제공하고 있어 고객들의 다양한 리포트 요구를 만족시킬 수 있게 되었다.포시에스는 지난 5-6년간 SK 텔레콤, 한국수력원자력, 예금보험공사, KBS, LG. PHILPS LCD 등에서 쌓은 기술력과 노하우를 바탕으로 고객들에게 필요한 리포트를 사전에 개발하여 이를 제공함으로써 즉각적인 활용이 가능하다. 유니센터 사용자는 관리 관점에 따라 개별 자원 정보를 하나의 보고서에서 동시에 분석할 수 있으며, 다수의 이기종 시스템 환경에 대한 종합적인 보고서 제공으로, 시스템간 비교 등 다각적인 분석을 통해 효과적인 관리 정책을 마련할 수 있다. 해외마케팅의 김종수 이사는 "해외 비즈니스의 가장 큰 걸림돌이 인지도 측면이었다. 제품을 마음에 들어 하다가도 한국 제품이라고 하면 일단 무시하는 것이 현실"이라며 "이번 스마트 인증으로 오즈의 기술력을 전세계적으로 인정받는 계기가 되어 기쁘다"라고 밝혔다. 현재 포시에스 인터내셔널은 CA와 OZ for Unicenter OEM 공급에 대한 논의가 진행중이고, OZ for Unicenter OEM 공급에 앞서 Teaming Agreement 계약을 통해 OZ for Unicenter 비즈니스을 위한 양사의 협조사항과 구체적인 진행 사항을 협의할 계획이다. <참조>ca smart 인증 : CA와 협력사 간의 긴밀한 협력을 통해 전세계적으로 펼치는 기술 개발 인증 프로그램으로, CA의 앞선 기술을 기반으로 e비즈니스 솔루션을 구축하는 소프트웨어 개발 업체들과 하드웨어 판매 업체 및 시스템 통합 업체의 품질과 혁신을 공인해주는 것이다. 이는 CA가 자사뿐만 아니라 협력사와 함께 고객들에게 최고의 품질과 최상의 e비즈니스 가치를 제공함으로써 디지털 경제 시대에 꼭 필요한 경쟁력을 확보할 수 있도록 지원한다는 데 의의가 있다.

Copyrightⓒ 2000-2003 edaily. All rights reserved.

이진우 기자 (voice@edaily.co.kr)