출처 : Outsider's Dev Story https://blog.outsider.ne.kr/
개개인이 가진 보안의 적정수준이란 건 당연히 다르기 마련이고 상황이나 입장에 따라 달라지게 마련이지만 평소 주위에 만연해 있는 보안에 대한 인식은 너무 과도하다고 생각한다.
큰 의미에서 보안이란 것은 대부분 어떤 가치 있는 무언가를 허가받지 않은 사람이 이용하지 못하도록 막는 것인데 내가 가진 보안에 대한 입장은 이용을 편하게 할 수 있는 수준을 보장한 뒤에 보안을 논해야 한다고 본다. 왜냐하면, 원래의 목적은 그 무언가를 이용하는 것이 1차적인 목적이고 그에 대한 부작용으로 허가받지 않은 사람이 사용하게 돼서 생기는 문제를 막기 위해 보안이 추가된 것이기 때문이다. 하지만 현실은 보안이 너무 과도해져서 이용 자체를 크게 저해하고 있다. 마치 이용을 막는 게 1차 목표인 것처럼...(물론 어디는 보안이 너무 과도하고 어딘가는 보안이 너무 빈약한 문제는 있다.)
예를 들어 보면 나는 집에 들어갈 때 우리 집 현관문에 달린 자물쇠를 열고 들어간다. 자물쇠는 2개가 달렸지만 보통 1개만 사용하고 장기간 비울 때만 2개를 사용한다. 다른 집도 비슷할 거라고 생각하는데 여태 살면서 가정집에 자물쇠 3개 이상 달린 집은 본 적이 없다. 만약 자물쇠가 종류별로 다른 인증체계를 가지고 자물쇠가 10개쯤 달려있다면 하나만 사용하는 것보다 당연히 더 안전할 것이다. 하지만 그렇게 하지 않는 이유는 현관문을 하루에도 수십 번씩 열어야 하기 때문이다. 지문인식부터 시작해서 열쇠를 다발로 가지고 다니면서 현관문을 오갈 때마다 일일이 십여 개씩 열고 다닌다면 보통 제정신이 아니라고 생각할 것이다. 영화에서 편집증에 걸린 사람이 이렇게 하는 거 외에는 실생활에서는 본 적이 없다. 현관문은 아니더라도 창문 등을 통해서 집에 들어오는 방법도 있다. 만약에 나갈 때 버튼 하나만 누르면 쇠로 된 셔터가 내려와서 모든 창문을 막아버리면 당연히 더 안전할 것이다. 마찬가지로 그렇게 하는 사람은 없다. 여기에는 비용문제도 있고 현관문과 마찬가지로 매일 사용해야 하므로 이런 짓거리는 하지 않는다.좀 과해 보이는 예시일 수도 있지만 내가 느끼기에는 IT에서 이러한 일은 빈번하게 일어난다. 보안은 중요하다는 명목하에서...
앞의 예제를 다시 보면 가장 쉬운 보안해결책은 집에 값진 물건을 두지 않는 것이다. 값진 물건을 두지 않으면(그래서 은행 같은 게 있는 거지...) 설사 보안체계가 뚫리더라도 위험이 크지 않다. 하지만 값진 물건이 있을 수밖에 없긴 한데 그렇다면 이 값진 물건에만 별도의 보안을 추가하면 된다. 당연히 생각해도 온 집안에 물건이 다 중요하진 않을 테니 절대 잃어버리면 안 되는 것만 별도의 금고에 넣거나 하면 된다. 이럴 때는 별도의 인증과정이 들어가도 아무도 불만을 품지 않는다. 번거로운 인증과정을 거칠 정도로 그 안에 들어 있는 것이 중요하기 때문이다. 그리고 이 부분은 이용성에도 문제가 되지 않는다. 내가 냉장고를 열고 물통을 꺼내는 횟수랑 금고에서 황금 송아지를 꺼내볼(
하지만 IT 환경을 보면 보안이라는 이유로 너무 많은 걸 보안영역 안에 넣어버린다. 그래서 원래는 이용하는 게 목적이었는데 너무 불편하므로 꼭 필요한 상황이 아니면 이용하지 않으려고 하게 된다. 내가 느끼기에 이 중에 80% 정도는 물통에서 물을 먹기 위해서 냉장고에 자물쇠가 걸려있는 꼴이다. 혹시 냉장고에 들어있는 물통이 나중에 값지게 될지도 모를 일이므로... 심지어 일해서 수익을 내는 회사에서도 이런 역전현상이 수시로 발생한다는데 당혹감을 감출 수 없는데 수많은 개발방법론을 도입해서 생산성을 조금이라고 올리는 것보다 보안을 조금 낮추는 게 훨씬 더 생산성을 높일 수 있을 거라고 본다.
왜 이런 일이 발생했는지는 나도 알 수 없다. 하지만 간단한 애플리케이션을 너무 과도하게 설계에서 성능이 제대로 나오지 않는다면 개발자가 해결해야 할 이슈이듯이 보안 때문에 생산성이 떨어진다면 이를 해결해야 하는 건 보안 쪽이다. 그리고 이런 무리한 요구도 아니고 이미 보안도 어느 정도 지키면서 생산성도 유지할 수 있는 기술은 충분히 개발되었다고 본다.
덧) 물론 이런 얘기를 하면 나중에 보안 문제로 재판 갔을 때 회사가 얼마나 보안에 대해 노력했느냐 하는 부분이 중요하다느니 어쩌느니 하는 얘기가 나오는데 재판을 안 가봐서 그런지 몰라도 별로 동의는 되지 않는다. 그거 해결하기 위해서 보안전문가가 있는 거 아닌가? 내가 개발을 더 쉽고 잘하기 위해서 원래 만들려던 서비스의 목적을 잃어버리고 야크 털만 깎고 있으면 잘했다고 해주나? 개발 열심히 잘했다고? 개발 자체가 목적이 아니라 서비스(혹은 무언가)를 만드는 게 목적이므로 그 중간은 어찌 되었든 내가 알아서 해결하고 결과물이 나와야 하는 거 아닌가?
덧) 왜 개발과 보안이 붙으면 항상 개발 쪽이 지는 걸까....
My Comment..
해당 포스팅을 읽으면서 내 상황과 많이 비교하게 되었다.. 아무래도 금융권쪽에 있다보니 보안이라는 부분과는 악어와 악어새 같은 입장이라고 해야될까.. 업무적인 롤이 되었건 인간관계적인 측면에서건 말이지.. 비교하는 부분이 좀 잘못된 걸수도 있는데 순간 딱 떠오른게 그렇다.. ㅎㅎ..
난 개발이라는 것을 처음 할 때 보안이라는 개념이 없었던 것 같다.. 그냥 아웃풋만 내면 되는거 아닌가..?? 라는 생각을 많이 했는데.. 지내다보니 표준, 취약성, 개인정보 관련 등등 무엇인가 엄청 많더라.. 그런데 그것의 정점을 찍은 것이 현 업무라고 생각한다.. 물론 더 높은 보안 수준도 있겠지만 최소한 내가 경험한 범주에서는 그러하다..
나는 햄의 글과 좀 비슷한 생각이 들기도 하고, 갈팡질팡하기도 한다.. 우선 과거 경험을 얘기해보면, 예전에 우리나라에서 나름 제일 크다고 하는 전산센터에 출장을 간일이 있었다.. 거기서는 보안 이슈 때문에 가방은 물론 호주머니까지 다 검사를 했으며, 담배 안에 무엇이 있는지도 검사했다.. 심지어 라이터는 압수를 했는데 어찌보면 사람이 문제를 일으킨다는 관점에서 물리적인 보안 점검을 그렇게 한다면 이해는 간다 당연히 불편하긴 하지만..
위와 같이 생각을 하면, 보안은 당연히 철저해야된다고 생각이 되기도 한다.. 문제가 생기면 결국 고생하는건 당사자가 되는 것이고 그로인해 문제의 영향도가 어디까지 파생될지 모르니 말이다.. 근데 또 한편으로 SW 개발적인 부분에서 다가서자면 특정 시스템 또는 특정 명령어에 대해서 다 제약을 걸어버리는 경우가 보안의 보편적인 룰일 것이다..
여기서 문제가 개발은 해야되고, 테스트도 해야되고, 오류가 있으면 확인해야될 자료가 있고 그런 것인데 그런 부분이 다 막히거나 특정인에게 요청해서 다시 피드백을 받고 그런 방식을 고수하면서 개발 데드라인은 과거와 똑같다..??? 이런것이 또 하나의 문제라면 문제 같다.. 얘기를 하다보니 이게 참.. 양면 색종이 같다..
보안을 생각하면 최대한 막는 것이 맞지만, 업무의 효율성을 위해서는 풀어주는게 좋고말이지.. 흠..;; 현재 업무하는 곳에서는 이제 어느정도 익숙해지긴 했지만 모든 보안이란 것이 어느 한쪽에 너무 치우쳐서 양극화를 만들어내기보단 그 중간을 유지하는 것이 결론적으로는 제일 좋은 것 같다.. 그 중간.. 중립을 유지하는게 제일 어려운것이 또한 문제긴 한다..
햄이 맨 마지막에 왜 항상 개발쪽이 지는 것일까.. 라고 했는데.. 글쎄 이부분은 현 시점에서는 다 그런건 아닌듯하다.. 머 일하다보면 대부분 지는거 같긴한데.. 그래도 과거와 비교한다면 많이 좋아진 것 아닌가 하는 생각을 살짝해본다.. ㅎㅎㅎ
댓글 없음:
댓글 쓰기