개발일지_2) 보안 그리고 깃허브

깃허브에 공개되는 코드는 모두가 열람할 수 있다는 점을 잊지 말자.

 

 

1.

 

주말 느지막이 침대에서 일어나다가 문득,

 

"깃허브에 올라간 나의 코드에 포함된 특정 정보를

누군가 악의를 가지고 사용한다면 어떠한 영향이 발생하는가"

 

에 대한 상상을 해봤다가 뒷덜미가 차가워지면서 침대 밖으로 뛰쳐나왔다. 

 

트위터에 이야기를 살짝 올려봤는데 역시나 현업에 계신 선생님 중 한 분이

현재 내 상황의 위험성에 대하여 조언을 해주셨다.

 

일단 위험한 일이 발생하지 않도록 막아 두었지만,

깃허브에 공개된 정보는 레파지토리가 남아있는 한

삭제 후 커밋 푸시를 하여도 로그에 남아있기 때문에

그동안 사용하고 있던 몇몇 가지를 폐기하기로 결정했다.

 

레파지토리 자체를 지우거나 비공개로 돌리기에는 아까운 작업물이었다.

그래도 일찍 깨달아서 다행이다.

비싸지 않은 선에서 좋은 경험을 했다 생각하기로.

 

깃허브에 공개되는 코드는 모두가 열람할 수 있다는 점을 잊지 말자.

 

 

 

 

2.

 

고민거리는 여전히 남아있다.

공개되서는 안 되는 정보를 분리, 캡슐화하여. gitignore에 포함시키는 방법을 사용하면

당장 그 정보가 퍼블릭한 공간(현 상황에선 깃허브 퍼블릭 레파지토리)에 노출되지는 않는다.

하지만 언젠가 프로그램을 공개해야 하고 

누군가 프로그램의 코드를 뜯어본다면 정보의 노출은 피할 수 없다.

 

당장 가까운 시일에 제한적인 사람들에게 프로그램 배포 계획이 잡혀있다.

이 문제를 어떻게 해결한 것인지

 

 

 

 

3.

 

 - 화이트리스트 접근 방식.

특정 자격을 가진 사람만이 정보를 사용 가능하게 만든다.

구현할 수만 있다면 가장 좋은 방법이 아닐까.

좀 찾아보겠지만 사실 감도 오지 않는다.

 

- 정보 노출의 암호화.

코드를 실행 가능한 형태로 변환하는 과정에서

원본 코드가 어느 정도 감춰지는지에 대한 지식이 없다.

c언어의 경우 컴파일 한 이후로는 원본 c 코드를 쉽게 복원이 안된다고 본 것 같다.

적어도 runable jar 파일은 압축 풀면 코드가 보인다.

이 방법 역시 당장 도입하기는 어려워 보인다.

 

- 정보의 이원화

로컬 에리어 밖으로 나가는 경우 폐기가 가능한 임시 정보를 이용한다.

이 방법은 제한시간 내에 구현이 가능할 것 같다.

그러나 개인 정보를 완전히 배제한 무작위 임시정보 작성 능력이 아직은 없다.

 

- 정보 유출의 최소화

제한 시간 동안만 사용할 수 있는 임시 정보 묶음을 만들어 관리한다.

부여된 시간을 공지하고 또 사용 이후에는 폐기하여 재사용하지 않는다.

혹여나 브루트포스 방식으로 유의미한 정보 값을 유추하더라도

발생하는 피해가 없도록 중앙 시스템과는 완전히 독립적으로 분리해둔다. 

또한 만일의 사태에 대비하여 백업을 철저히 해둔다.

 

 

 

 

4.

 

조금은 주제에 벗어난 이야기.

 

개발 공부를 시작한 지 약 7개월이 지났다.

시연할 프로그램은 개발기간 1개월의 프로젝트다.

지금까지 내가 만들었던 어느 프로그램 어느 코드보다도 사랑이 많이 담겨있다.

 

시연 프로그램은 30명 이내의 사람들에게 배포한다.

더 많은 사람들에게 내 프로젝트를 공개하고 배포하고 사용해주었으면 좋겠다고 생각하지만

보안이라는 벽이 나를 막고 있다.

나를 막고 있다는 것을 인지했고 알았고 배웠다.

 

최근 마음에 들어서 자주 되뇌는 말이 있는데ㅋㅋ

손과 발이 심히 오그라들지만 

그래도

 

답은 언제나 있다. 아직 찾지 못했을 뿐

그리고 찾아낼 것이다

내가 언제나 그래 왔듯이

 

 

 

2월 5일

약간은 한가롭고 늘어지는 기분 좋은 어느 주말에 작성