LogIn 의미

 

컴퓨터 보안에서 로그인(login: 등록가입)과 로그아웃(logout)은 접근 허가 증명을 얻기 위해 사용자 인증으로 개인이 컴퓨터 시스템에 접근하는 작업을 말한다. 컴퓨터 보안에서 중요한 역할을 담당한다. 사용자 자격 증명은 일반적으로 사용자 이름과 그에 일치하는 비밀번호 형태를 이루며 이를 기반으로 사용자는 접근을 얻기 위해 시스템에 로그인할 수 있으며 더 이상 필요하지 않을 때 로그아웃할 수 있다.

 


 

로그인의 기원

 

우리는 매일, 하루에도 수십 번씩 로그인을 합니다.

하지만 왜 로그인이라고 부르는지 모릅니다.

 

로그인의 뜻을 생각해보면 이상하게 들릴 수 있는 문구입니다.

온라인에서 많이 사용돼서 흔히 어떤 서비스에 자신의 계정으로 시작한다는 의미 정도로 알고 있지만,

로그인이라는 단어의 유래를 깊게 찾아본 사람은 많지 않습니다.

 

 

OED에서 "컴퓨터에 대한 온라인 엑세를 여는 것"이라는 현대적 의미의 "로그인"을 사용한 최초의 사례는 1963년 출판물인 MIT의 Compatible Time-Sharing System에서 가져온 것입니다.

이 시점이 "로그인"의 첫 번째 사용인지 확실하지 않지만 1961년에 시작된 CTSS가 틀림없이 최초의 시분할 운영 체제라면 말이 됩니다.

가장 먼저 로그인해야 하는 시스템이기도 합니다. (이전에는 일괄 처리 시스템만 있었습니다.)

 

CTSS든 비슷한 시스템이든, 1959년에서 1961년 사이에 MIT에 있는 엔지니어가 그들이 만들고 있는 시스템에 대한 새로운 사용자 명령을 설명할 필요가 있다고 생각합니다.

우리는 이러한 상황에서 많은 신조어를 얻으며, 역사상 로그인이 시작된 날은 지금 이 순간부터입니다.

 

 

시분할 시스템 이전에 '로그인'이 컴퓨터 이외의 의미로 사용되었을 가능성도 있지만, 다른 자료들에서 찾을 수 없었습니다.

그러나 물론 어떤 것 또는 누군가를 기록한다는 의미의 "로그" 부분은 컴퓨터보다 수백 년 앞서 있었습니다.

 

 

이 사용법은 OED에서 정의하는 "로그북" 또는 선박의 로그(또는 스타플릿에 있는 경우 선장 로그)에 무언가를 입력하는 것의 단축됩니다.

항해일지에서 선박의 항해 내용(일지에 표기된 선박의 진행률 포함)을 매일 입력하는 책입니다.

log-book 또는 logbook의 첫 번째 나열된 사용법은 대략 1689년부터입니다( J. Moore's  New Syst. Math ). 

250년 전으로 돌아가면서, 우리는 컴퓨터 시스템의 우리 자신을 확인하는 것에서 항해하는 배의 속도를 책에 입력하는 것으로 변했습니다.

그런데 왜 로그북이라고 불렸을까요? 칩 로그, 선박 로그, 로그 등으로 다양하게 불리는 이 장치 때문에 다음과 같습니다.

 

 

통나무 아니면 매듭(knot)이 있는 밧줄에 달린 무거운 나무 조각을 배 밖으로 던져서 정해진 시간 동안 얼마나 많은 매듭(knot)이 지나가는지, Wikipedia에서 설명하는 대로 시간을 측정합니다.

예전에는 배의 속도를 확인할 때 미리 밧줄에 매듭 표시를 한 부표를 던져놓고 일정 시간이 지난 후 그동안 몇 매듭(knot)이 지나갔다 확인합니다. 그 매듭(knot)의 수가 배의 속도였습니다.

 

 

이미지 참조 : https://en.wikipedia.org/wiki/Chip_log

 

이것이 우리가 여전히 항해 속도를 매듭으로 측정하는 이유이기도 합니다.

그래서 컴퓨터로 어떤 서비스에 접속하여 기록을 남기기 시작할 때 "Login" 한다고 말하거나, 접속을 종료할 때 "Logout"을 사용하게 되었다고 추측합니다.

하지만 일반인들이 평소에 사용하던 단어가 아니고 단어만 들었을 때 이해되지 않았습니다.

그래서 "Login"이라는 단어가 낯설게 다가와서 "Signin"으로 사용하거나,

"Logout" 대신 "Signout" 등 같은 의미지만 다른 단어들이 사용되고 있습니다.

 

 

후기

 

"Login"이라는 단어를 외래어처럼 사용했는데, 유래를 알고 나니 되게 재밌습니다.

사실 이렇게 파고든 이유는 개발에 영향이 큽니다.

예전에는 Spring을 사용하면 그냥 이름이 Spring이고 사람들이 많이 사용하니 좋은 프레임워크구나 싶어서 사용을 했는데, Spring의 유래와 프레임워크의 유래까지 찾다 보니 새로운 사실들을 많이 알게 되었고 뿐만 아니라 다른 프레임워크를 사용하지 않고 왜 Spring을 사용하는지까지 찾다보니 이렇게 한 가지에 파고드는 습관이 생겼습니다.

단순히 사람들이 사용하니깐 사용하는 것이 아닌 무언가 발명이 되었으면 발명이 된 이유가 있을 것이고, 그게 지금 나에게 왜 필요한지까지 생각해보게 되었습니다.

감사합니다.

 

참조 자료: http://www.designcult.org/2011/08/why-do-we-call-in-logging-in.html

참조 자료: https://ko.wikipedia.org/wiki/%EB%A1%9C%EA%B7%B8%EC%9D%B8

'스프링 > LOG' 카테고리의 다른 글

[LOG] log4j 보안취약점 업데이트 권고 내용  (0) 2021.12.30
링크

 

https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=36397 

 

KISA 인터넷 보호나라&KrCERT

KISA 인터넷 보호나라&KrCERT

www.boho.or.kr

 


 

이슈

 

Log4j 2에서 발생하는 취약점에 대해 Apache 소프트웨어 재단이 보안 업데이트를 권고하였습니다.

이는 보안 위협 수준 1~10단계 중 최고 단계인 10단계에 해당한다고 설명하고 있습니다.

공격자는 해당 취약점을 이용하여 정상 서비스 중지 등의 피해를 발생시킬 수 있으므로, 최신 버전으로 업데이트를 권고하였습니다.

JNDI 정보와 LDAP의 정보를 알 수 있다고 합니다.

 

방안

 

 - Java 8 이상 : Log4j 2.17.1으로 업데이트
 - Java 7 : Log4j 2.12.4으로 업데이트[5] - Java 6 : Log4j 2.3.2으로 업데이트[5]

※ log4j-core-*.jar 파일 없이 log4j-api-*.jar 파일만 사용하는 경우 위 취약점의 영향을 받지 않음

 

후기

 

현재 온라인상에 나와있는 대처방법으로는 Apache Log4j 보안 업데이트 권고에 있는 취약점 버전을 사용하지 않고, 신규 버전을 사용하는 방법이 있습니다.

이슈가 되는 내용은 해커들의 공격으로 JNDI 정보와 LDAP 정보를 알아낼 수 있다고 합니다. 

현재 취약점 버전을 사용하고 있고, 문제가 되는 JNDI와 LDAP를 사용 중이라면 긴급조치를 해야 할 것입니다.

하지만 현재 운영 중인 서버에 JNDI와 LDAP를 사용하고 있지 않다면 어떻게 해야 할까요?

앞으로도 JNDI와 LDAP를 사용하지 않는다면 Log4j 취약점 버전을 그대로 유지해도 될까요?

현재 이슈는 개발자 커뮤니티뿐 아니라 사회적으로 이슈가 되었습니다.

현재 운영 중인 서비스가 있다면 서비스를 이용하는 고객에게 문의가 올 수 있습니다.

답변으로 우리 회사 서비스는 취약점에 포함된 버전을 사용하고 있지만 JNDI와 LDAP를 사용하지 않으니 변경할 예정이 없다고 한다면 고객이 이해할 수 없다고 생각합니다.

고객에게 문의가 왔다면 Log4j 업데이트를 우선순위로 둬서 작업을 진행해야 할 것입니다.

하지만 고객에게 문의가 오지 않는다면 일정을 잡아서 취약점에 해당하는 버전들은 업데이트를 해야 할 것입니다.

감사합니다.

 


 
참고사이트

[4] 취약점 정보 : https://nvd.nist.gov/vuln/detail/CVE-2021-44832
[5] Log4j 2.12.4, 2.3.2 다운로드 : https://archive.apache.org/dist/logging/log4j/

 

'스프링 > LOG' 카테고리의 다른 글

[LogIn]의 기원  (0) 2022.01.03

+ Recent posts