| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 |
- xor
- 비밀번호보안
- 강의
- 암호학
- 개발자
- 보안기초
- 암호화
- 사이버보안
- ReplayAttack
- 전자서명
- 취약점
- 경사하강법
- 메시지인증
- 머신러닝
- 계정보안
- 해시
- 디지털서명
- 인증
- 키전송
- 공개키
- 비밀번호해시
- 정보보안
- 인공지능
- AI보안
- lootnip
- 파일무결성
- 재전송공격
- ZeroKnowledgeProof
- 웹보안
- 루니프
- Today
- Total
목록전체 글 (240)
루니프의 짤막보안강의
분야: 정보보안파일을 서버에 올리거나 다른 사람에게 전달할 때, 로그인 화면이 보인다고 해서 전송 과정까지 안전한 것은 아닙니다. 파일이 이동하는 동안 내용이 읽힐 수 있는지도 확인해야 해요.결론부터 말하면 FTP와 SFTP는 전송 구간의 암호화 여부를 기준으로 구분합니다. 일반적인 기술 설명에서는 FTP는 암호화가 기본 제공되지 않는 방식이고, SFTP는 SSH(Secure Shell) 보안 채널 안에서 파일을 전송하는 방식으로 설명합니다.다만 이번에 제공된 자료에는 FTP와 SFTP의 상세한 프로토콜 설명이나 세부 설정 기준이 없습니다. 따라서 아래 내용은 기본 개념을 이해하기 위한 설명으로 보고, 실제 운영이나 시험에서는 서버·클라이언트 설정과 공식 문서를 함께 확인해야 합니다.파일 전송 프로토콜이..
출처: https://www.boannews.com/news/articleView.html?idxno=145981로그인이 되지 않거나 중요한 파일을 열 수 없는 상황을 떠올려 보세요. 많은 사람은 먼저 “공격을 완전히 막았어야 했다”고 생각합니다. 하지만 보안은 침입을 막는 데서 끝나지 않습니다. 문제가 생겼을 때 업무와 서비스를 다시 운영할 수 있도록 준비하는 일도 보안의 중요한 부분입니다.제공된 보안뉴스 오피니언은 이 관점의 전환을 다룹니다. 완벽한 방어만 기다리기보다, 침해 가능성을 전제로 대응과 복구를 함께 설계해야 한다는 내용입니다.완벽한 방어가 어려워진 이유보안에서 방어는 여전히 필요합니다. 계정과 데이터를 보호하고, 허가받지 않은 접근을 막아야 합니다. 다만 방어선이 있다고 해서 모든 침해 ..
분야: 네트워크 기반 공격기술의 이해 및 대응카페 와이파이나 회사 네트워크를 사용할 때, 누군가 다른 기기인 척 접근하는 상황과 오가는 통신을 몰래 살피는 상황은 비슷하게 느껴질 수 있습니다. 하지만 두 공격은 문제가 발생하는 지점이 다릅니다.이 글에서는 스푸핑과 스니핑을 처음 접하는 분을 위해 먼저 차이를 간단히 정리합니다. 이어서 인터넷 프로토콜 주소와 MAC 주소가 왜 스푸핑 설명에 등장하는지 살펴보겠습니다. 다만 제공된 출제기준 발췌는 IP·MAC 주소 위조의 구체 방식까지 설명하지 않으므로, 그 부분은 확인이 필요한 범위로 구분합니다.기억할 기준은 간단합니다. 스푸핑은 ‘누구인지 속이는 쪽’, 스니핑은 ‘오가는 통신을 살피는 쪽’입니다.먼저 알아둘 개념: 네트워크 주소기기끼리 네트워크로 통신하려..
분야: 정보보안·암호학파일을 통째로 암호화할까요, 아니면 메시지가 들어오는 즉시 조금씩 처리할까요? 이때 비교하게 되는 개념이 블록 암호(Block Cipher)와 스트림 암호(Stream Cipher)입니다. 결론부터 말하면 데이터의 형태만 보고 하나를 고르는 것이 아니라, 암호 알고리즘과 운용모드(Mode of Operation), 처리 조건을 함께 확인해야 합니다.먼저 알아둘 개념: 대칭키 암호대칭키 암호(Symmetric-Key Cryptography)는 암호화와 복호화에 같은 비밀키를 사용하는 암호 방식입니다. 보내는 쪽과 받는 쪽이 같은 키를 안전하게 공유해야 한다는 점이 출발점이에요.그 안에서 블록 암호와 스트림 암호는 데이터를 처리하는 관점이 다릅니다. 다만 이번 주제의 출처인 S1 발췌에..
외주 개발자가 프로젝트를 떠났는데, 그 사람이 사용하던 API 키(API key)가 아직 살아 있다면 어떻게 해야 할까요? 이 사례의 핵심은 기존 키를 폐기하고, 꼭 필요한 접근만 좁은 권한으로 남기는 순서입니다.다만 제공된 기록만으로 해당 키가 실제로 유효한지, 어떤 서비스에 연결됐는지, 무단 사용이나 피해가 있었는지는 확인되지 않았습니다. 따라서 실제 사고가 발생했다고 단정하지 않고, 제시된 상황을 가정한 대응 순서로 살펴보겠습니다.키를 보관하는 위치와, 그 키가 지금도 접근할 수 있는지는 별개의 문제입니다.API 키와 환경 변수부터 이해하기API 키는 서비스에 접근할 때 요청자를 확인하는 데 사용하는 비밀 값입니다. 예를 들어 어떤 프로그램이 외부 서비스에 요청을 보낼 때, 서비스는 키를 보고 허용..
출처: https://www.securityweek.com/organizations-warned-of-3-exploited-linux-kernel-vulnerabilities/운영 중인 서버에서 “리눅스 커널 취약점이 실제 악용 목록에 올랐다”는 경고를 봤다고 해보죠. 바로 서비스를 멈춰야 할까요, 아니면 다음 정기 점검까지 기다려도 될까요?결론부터 말하면, 패치 우선순위는 즉시 높여야 하지만 서비스 중단은 별도로 판단해야 합니다. 먼저 어떤 자산이 영향을 받는지와 사용 중인 커널 버전을 확인해야 합니다. 그다음 패치와 운영 대체 절차를 검토하고, 중단이 필요한지 결정해야 해요.먼저 알아둘 개념: 커널과 KEV리눅스 커널은 무엇인가요?커널은 운영체제의 핵심 부분입니다. 프로그램이 메모리, 네트워크, 저장..
