티스토리 뷰

1.2 해커, 그들의 해킹 모델과 대응 방법들

 

인터넷과 같은 거대한 컴퓨터 네트워크 상에서 발생 할 수 있는 보안을 위협 하는 행위,

 

즉 해킹 모델에 대하여 예를 통해서 알아 보도록 하겠습니다. 그리고 이 해킹 모델에 대하여

 

암호화는 어떤 역할을 하는지도 역시 같이 알아 보겠습니다.

 

 

1.2.1 서버 안의 데이터에 대한 보안

 

보안상의 위협이 꼭 네트워크 상에서만 벌어지는 것은 아닙니다.

 

가장 위험한 적은 내부의 적이라고 할 수도 있을 것입니다.

 

만약 내부의 악의적인 누군가가 내가 자리를 비웠을 때 내 책상에 앉아서

 

내 컴퓨터 안의 특정한 자료를 몰래 복사해 갈 수 있을 것입니다. 이런 중요한 정보의 유출이 있어선 안될 것입니다.

 


[그림] 자신의 컴퓨터에 저장된 데이터를 보호 해야 한다

 

암호화는 이런 자신이 가지고 있는 중요한 데이터를 보호 할 수 있는 방법을 제공 합니다.

 

데이터를 암호화 하여 자신 이외의 사람은 볼 수 없게 만들 수 있습니다.

 

 

1.2.2 상대방에게 전송 하는 데이터에 대한 보안

 

네트워크를 통하여 상대방에게 어떤 메시지를 전송 하려고 할 때,

 

네트워크의 중간에 누군가가 이 메시지를 가로 채기는 쉽습니다.

 

인터넷 같은 컴퓨터 네트워크에서는 내가 보낸 메시지가 상대방에게 전달 될 때까지

 

무수히 많은 컴퓨터 혹은 라우터 같은 네트워크 기기를 경유합니다.

 

이렇게 많은 컴퓨터를 경유 하는 사이에, 누군가가 메시지를 가로 채는 것은 매우 간단한 일입니다.

 

특히, 메시지를 가로 채려는 누군가가 나, 혹은 상대방과 같은 서브 네트워크 하에 있다면,

 

메시지를 가로 채거나 몰래 얻기는 너무나 쉬운 일입니다.

 

보통의 네트워크 카드에는 듣기 모드가 있어서 자신과 같은 서브 네트워크 안에 있는

 

모든 네트워크 패킷의 내용을 들을 수 있습니다. 따라서 이 패킷들을 수집해서 내용을 분석 한다면,

 

특정 주소로부터 보내고, 받은 내용을 얻는 것은 아주 간단한 일입니다.

[그림] 상대방에게 보내는 정보에 대한 보호가 있어야 한다

 

암호화는 주고 받는 데이터를 암호화 함으로서 나와 상대방 이외에는 데이터의 내용을 알 수 없게 합니다.

 

따라서 메시지 데이터를 누군가가 몰래 얻었다고 해도 이 내용을 알 수 없으므로 데이터의 내용을 보호할 수 있습니다.

 

 

1.2.3 내가 정보를 보내려는 상대 방이 누군지 알 수 있음

 

내가 정보를 보내는 곳이 내가 원하는 상대방이 아니라 상대방인척 하는 해커 일 수도 있습니다.

 

컴퓨터 네트 워크 상에서 상대방에게 중요한 정보를 보낼 때, 중간에 누군가가 정보를 몰래 얻는 것도

 

보안을 크게 위협 하는 요소 이지만, 이렇게 내가 원하는 곳이 아닌 곳에 정보를 보내는 상황도

 

역시 정보의 보안을 크게 위협 합니다.

[그림] 내가 통신하는 사람이 A라는 것을 확신 할 수 있어야 한다

 

이를 방지 하기 위해서는, 내가 정보를 보내려는 상대방이 정말로 내가 정보를 보내기를

 

원하는 사람이 맞는 지를 확일 할 수 있어야 합니다. 암호화는 이러한 방법을 제공해 줍니다.

 

 

1.2.4 내가 보내는 정보를 중간에 누군가가 변경 시키지 못하게 함

 

이 경우는, 내가 보내는 정보를 누군가가 몰래 얻어서 그 정보의 내용을 악의적으로 사용 하는 것이 아니라

 

정보의 내용을 변경 하는 것입니다. 상대방은 그 누군가가 변경한 메시지를 내가 보낸 메시지 인줄 알 것이므로

 

경우에 따라 심각한 문제가 발생 할 수 있을 것입니다.

 

이를 방지 하기 위해서는 메시지를 받은 쪽에서는 메시지를 원래 보낸 사람 이외에

 

누군가가 변경을 가한 흔적이 있나를 알 수 있는 방법이 제공 되어야 합니다. 암호화는 이런 방법을 제공해 줍니다.

 

메시지를 보낸 사람 이외에 중간에 누군가가 변경 했다면 메시지를 받은 사람은 즉시 메시지 변경을 알 수 있습니다.

 

 

1.2.5 내가 받은 정보가 중간에 누군가에 의해 변경되었는지 아닌지 알 수 있음

 

내가 받은 메시지도 위의 상황과 마찬 가지 입니다.

 

암호화를 사용 하면, 누군가가 메시지를 변경 했는지 아닌지를 알 수 있습니다.

 

 

1.2.6 상대방이 메시지를 보내고도 안 보냈다고 부인을 할 수 없게 함

 

예를 들어서 어떤 사람이 자신에게 A라는 기업의 주식이 지금 매우 싸니까 만 주를 사라는 메시지를 보내왔습니다.

 

그리고 만약 손해를 본다면 자기가 책임 지겠다는 내용도 같이 메시지 안에 넣었습니다.

 

하지만 A라는 기업의 주식이 가격은 떨어졌고, 손해를 보게 되었습니다. 따라서 메시지를 보내왔던

 

상대방에게 책임을 지라고 했지만, 상대방은 자신은 그런 메시지를 보내지 않았다고 합니다.

 

이런 경우에 우리는 그 메시지가 상대방으로부터 온 것이라고 증명할 어떠한 증거도 가지고 있지를 못합니다.

 

상대방인척 하는 누군가가 보낸 메시지 일 수도 있으니까요.

[그림] B는 자신이 보내고도 안 보냈다고 할 수 없다

 

이를 방지 하기 위해서는 메시지를 보내지 않았다고 하는 부인을 방지 할 수 있는 기능이 제공 되어야 합니다.

 

암호화는 이러한 기능을 제공 할 수 있습니다.

 

 

1.2.7 서버는 허락되지 않은 사용자의 접근을 차단

 

중요한 정보가 저장되어 있는 서버는 허락된 사용자만 들어 올 수 있어야 합니다.

 

중요한 정보는 문서가 될 수도 있고, 이미지나 동영상 같은 정보가 될 수 도 있습니다.

 

또한 이 외에도 많은 종류의 데이터가 중요한 정보가 될 수 있습니다. 서버는 이러한 정보를 보호 해야 합니다.

 

따라서 이미 정해진 인증된 사용자만 서버에 접속을 허락 해야 할 것입니다. 악의적인 누군가가 서버에 들어

 

온다면 정보는 더 이상 보호 되지 못할 것입니다.

[그림] 정해진 사용자만이 접속 할 수 있어야 한다

 

이를 방지 하기 위해서는 서버에 접속 하는 사용자들을 인증 하고, 인증 되지 않은 사용자는

 

서버의 접근을 차단 해야 합니다. 암호화는 이런 면에 있어서 매우 효과적인 방법을 제공 합니다.

 

 

1.2.8 서버는 패스워드 같은 낮은 수준의 인증 수단보다 훨씬 강력한 인증 수단을 사용

 

은행이나 주식 거래와 같은 전자 상거래를 제공 하는 사이트는 해당 계좌와 이에 해당 되는 사용자가

 

맞는 지 인증 해야 합니다. 이를 위해서 패스워드와 같은 간단한 인증 수단으로는

 

악의적인 누군가에 의한 접근을 막기에는 부족한 면이 많습니다. 누군가가 사용자의 패스워드만

 

몰래 얻을 수 있다면 이 패스워드를 이용 해서 사용자의 계좌에 있는 돈을 자신의 계좌로 이체 할 수도 있을 것입니다.

 

이와 같이 사용자의 인증이 매우 중요한 상황 에서는 패스워드와 같은 간단한 인증 수단이 아닌,

 

강력한 인증 수단이 제공 되어야 합니다. 암호화는 충분히 아주 강력하나 사용자의 인증 수단을 제공해 줍니다.

 

 

1.2.9 내가 접속하려는 서버가 옳은 서버 인지 알 수 있음

 

물건을 사려고 쇼핑몰 사이트에 접속 했다고 가정 합니다. 물건을 사려면 돈을 지불 해야 합니다.

 

인터넷 쇼핑몰에서 돈을 지불 하는 가장 쉬운 방법은 카드로 구매 하는 것으로, 카드 번호와, 비밀 번호 등

 

부가 정보를 쇼핑몰 측에서 제공 하는 페이지에서 입력 해야 합니다. 이 정보는 쇼핑몰로 전송 되고,

 

쇼핑몰에서는 이 정보를 이용해 카드 회사에 물건 구매를 알립니다. 그런데 이 쇼핑몰이 악의적인 누군가가

 

만든 것으로서, 실제로 물건을 팔지는 않고 사용자의 카드 정보만을 입수 해서,

 

그 정보를 나쁜 곳에 사용 할 수 있는 상황이 발생 할 수 있을 것입니다.

 

이를 방지 하기 위해서는 사용자에게도 자신이 접속 하려는 서버가 옳은 곳인지를 인증 하는 방법이

 

제공 되어야 합니다. 암호화는 이런 방법을 제공해 줍니다.

'P rogramming > E ncryption' 카테고리의 다른 글

메시지 다이제스트 ( MD )  (0) 2012.08.06
MD5  (0) 2012.08.03
1.3 고대 암호 예문  (0) 2012.08.03
1.2 해커와 대응 방법  (0) 2012.08.03
1.1 암호화  (0) 2012.08.03
댓글
댓글쓰기 폼