SKT 서버에서 털린건 메모리DB인데요, 암호화 안 했다. 분노하시는건 이해하지만.

서버 메모리를 암호화 하는건 불가능하고, 그래서 왜 법적으로 이 내용은 암호화 해야 하는 내용에서 빠졌는지 이해는 하자는 취지로 글을 적습니다.

제가 db의 기본도 모르네 하시는 분이 계셔서, 정확한 내용을 근거에 의해 설명을 드립니다.

암호화를 하는건 서버에 있는 DB이지(DB 서버가 따로 있을 수도 있지요.) 서버의 메모리가 될 수는 없습니다.

패스워드를 암호화 해서 보관하는건 당연한거지요.

유저의 컴퓨터에서 패스워드를 입력하면, 패스워드는 암호화 된 후, 서버로 전송되지요.

그리고 서버에 도착한 후에는, 암호화가 풀려서 평문이 되지요. 그리고 메모리에 올리지요.

그리고 서버의 DB에서 암호화된 유저 패스워드의 암호화를 풀어서 메모리에 올리지요.

그리고 두개를 비교하고, 일치하면 유저에게 권한을 주지요.

이 경우에서 볼 수 있듯이, 메모리DB를 암호화 해 놔도, 결국은 메모리에서 또 암호화가 풀려요.

그렇다면 메모리를 탈취 할 수 있는 BOT을 서버에 올리면, 아무리 암호화를 해도 소용이 없어요.

결국 메모리에서 암호화가 풀리거든요.

실제로 많이 사용하는 메모리 DB중, 아마존 메모리 DB와  redis 관련 내용을 봐 보면요.

메모리 DB는 메모리에선 암호화를 전혀 하지 않습니다.

계속 적지만, 결국 메모리를 암호화를 해 봤자, 비교를 할려면, 메모리에서 암호화를 또 풀어야 하거든요.

암호화가 되는 구간은 전송이 되는 구간이에요. 서버 자체의 메모리를 터는 BOT이 돌고 있으면,

무슨 암호화를 해도 작업하는 중에는 털릴 수 밖에 없어요.

그래서 실제로 암호화가 되는건 전송 중에 암호화를 하는 것입니다.

물론 파일을 보관중에도 암호화를 하지요. 그런데 보관중인 파일 조차도 메모리에서 실제로 사용될때에는 암호화가 풀려요.

맨 처음에 적었던 DB에 암호화되어서 보관중인 패스워드조차도, 비교를 위해서 메모리에 올라갈때에는 암호화가 풀려요.

SK측에서도 인정했다시피, 보안상의 문제는 있었습니다. 그래서 유출이 생긴거지요.

(책임은 SK측이 얼마나 지는지, 방화벽 회사쪽에서 얼마나 지는지 문제는 있겠지만요.)

세상에 서버 메모리를 암호화하는 경우는 없습니다. 결국 비교를 할려면 또 서버 메모리에서 암호화가 풀려야 하니까요.

그래서 제가 이전 글에서 적었듯이, 메모리를 탈취해서 전송하는 BOT이 따로 있고.

권한을 탈취하는게 따로 있는 이중 구조일 것이라고 한겁니다. (SKT 대리점측에서 권한 탈취나 협력이 있었을거라고 보는겁니다.)

SKT측이 물론 잘못 했지만, 최첨단 메모리DB도 서버 메모리 자체를 암호화 하진 않습니다.

몇번 적었는지도 모르겠지만, 메모리 자체를 암호화 해도, 비교할려면 결국 메모리에서 암호화를 풀어야 하니까요.

암호화 되지 않은 상태로 보관했다. 분노하시는건 알겠지만. 메모리를 아무리 암호화 해도 결국 비교하고 사용할려면,

메모리에서 암호화를 푸니까, 메모리 암호화는 소용이 없습니다. 전송이나 보관시에 암호화를 하는것이죠.

** 이게 가능한게, 정확히는, 메모리가 아니라, 트렌젝션을 담당하는 프로그램이 따로 있을 거라고 봅니다.

이 부분은 기술적으로 조금 까다로워서 이 정도 분량의 글을 하나 더 적어야 해서. 최대한 간단히 메모리를 탈취 했다고 한겁니다.

기술적으로 엄밀하진 않은데요....트렌젝션을 탈취하는걸 메모리를 탈취하는걸로 간략화 했습니다.