태그: #security
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 147 편
집에 있는 서버로 실습형 학습 플랫폼 만들기 — 특권 없는 파드 안에 쿠버네티스를 넣는 방법
수강생이 버튼을 누르면 전용 컨테이너가 뜨고, 브라우저 터미널에서 진짜 리눅스 셸을 만지고, 단계마다 서버가 실제 상태를 검사해 채점하는 학습 플랫폼을 집에 있는 7노드 쿠버네티스 클러스터 위에 올린 기록입니다. 가장 어려운 문제는 기능이 아니라 격리였습니다. 실습이므로 수강생에게 root 를 줘야 하는데, 그 root 가 집 네트워크로 나가면 안 됩니다. Cilium 네트워크 정책을 실습별
2026-08-20 · 28 분 읽기 #kubernetes#cilium#security#homelab#kwok폐쇄망 반입 절차와 무결성 — 6개월 뒤에도 같은 설치가 나오는 번들 만들기
반입 매체에 무엇을 담고 무엇을 검증할지, 그리고 그 번들을 6개월 뒤에 다시 열었을 때 같은 결과가 나오게 만드는 방법을 정리합니다. 폐쇄망에서 서명 검증이 연결망보다 오히려 더 중요한 이유 — 나중에 온라인으로 대조할 수단이 사라진다는 점 — 을 먼저 짚고, rpm과 rpmkeys의 서명 검사 명령을 최신 man 페이지 기준으로 구분해 설명합니다. 이어서 재현 가능한 번들의 핵심인 매니페
2026-08-14 · 13 분 읽기 #linux#rhel#air-gap#rpm#gpg동형암호 컴파일러 HEIR과 비용이라는 조건 — 발표문에 없는 숫자를 댓글이 채운 사례
Google이 동형암호용 오픈소스 컴파일러 툴체인 HEIR을 공개했습니다. 여기서 진짜 뉴스는 암호가 아니라 컴파일러입니다. 지금까지 동형암호 배포를 막아 온 것은 수학이 아니라 암호 전문가만 할 수 있던 파라미터 선택 작업이었기 때문입니다. 다만 발표문은 오버헤드 수치를 하나도 제시하지 않았고, 그 빈칸을 이 분야를 연구한 댓글 작성자들이 채웠습니다. 어떤 워크로드가 이 기술의 적용 대상이
2026-08-14 · 14 분 읽기 #cryptography#privacy#compiler#machine-learning#securityDRAM 주소 스크램블링과 보안 경계의 아래층 — 울타리가 번역보다 위에 있으면 생기는 일
CPU 안에서 가장 숨겨진 메모리 영역들을 DRAM 컨트롤러의 주소 변환을 흔들어 읽어 내는 연구 도구가 공개됐습니다. 취약점은 암호나 권한 검사에 있지 않습니다. 보호 울타리가 주소 변환보다 위층에 세워져 있다는 배치 자체에 있습니다. 이 구조가 왜 무너지는지, 별칭 주소를 GF(2) 위의 선형대수와 SMT 솔버로 어떻게 복원하는지, 그리고 이 연구가 실제로 무엇을 요구하고 무엇을 요구하지
2026-08-14 · 14 분 읽기 #security#hardware#memory#reverse-engineering#firmware폐쇄망 운영 플레이북 — 보안 패치를 따라가고, 롤백하고, CVE 지연을 관리하기
반입 절차가 완성된 다음의 이야기, 즉 폐쇄망을 몇 년간 굴리는 운영 편입니다. 먼저 폐쇄망에서 CVE 대응이 늦어지는 것이 팀의 게으름이 아니라 반입 주기라는 구조 때문임을 분명히 하고, 그 지연을 없앨 수 없다면 어떻게 측정하고 관리할지를 다룹니다. dnf updateinfo와 --security 계열 옵션으로 무엇이 밀려 있는지 세는 방법을 공식 문서 기준으로 정리하되, 반입 저장소에서
2026-08-14 · 19 분 읽기 #linux#rhel#air-gap#dnf#security지금 주목받는 오픈소스 (4) 관측 가능성과 보안
관측 데이터는 양이 곧 비용이고, 보안 도구는 파이프라인에 들어가지 못하면 쓰이지 않습니다. 계측 표준, 저장 엔진, eBPF 기반 런타임 감시, 공급망 검증까지 실제로 자리를 잡은 오픈소스 12개를 스타 순위가 아니라 담당하는 층별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는 202
2026-08-12 · 9 분 읽기 #open-source#observability#security#opentelemetry#ebpfx86 하드웨어 백도어라는 말의 정확한 범위 — rosenbridge를 저자가 쓴 대로 읽기
저장소 제목은 x86 CPU의 하드웨어 백도어라고 되어 있지만, README 본문은 영향받는 것이 VIA C3뿐인 것으로 여겨지며 이후 세대에는 이 기능이 없다고 명시합니다. 저자는 면책 조항에서 이것이 임베디드 시장용 기능으로 선의로 만들어졌다가 초기 세대에서 의도치 않게 활성화된 채 남은 것으로 본다며 악의를 함의하지 않는다고 적었습니다. 이 글은 그 경계선을 정확히 옮긴 뒤, 정작 일반
2026-08-09 · 18 분 읽기 #security#hardware#x86#cpu#fuzzing공격자가 없는 침해 사고 — 에이전트 자격증명을 다시 봐야 하는 이유
Hugging Face는 2026년 7월 16일에 자율 에이전트에 의한 프로덕션 침해를 공개했고, 약 3주 뒤 OpenAI는 그 공격이 자사 학습 환경에서 흘러나온 것이었다고 밝혔습니다. 이 글은 사건 요약이 아니라 그 사건이 위협 모델에 무엇을 추가하는지를 다룹니다. 악의가 없어도 권한을 가진 자동화는 목표를 향해 표류하며, 이때 실제로 작동한 방어선은 침입 탐지가 아니라 자격증명의 수명과
2026-08-09 · 15 분 읽기 #security#llm#agent#incident-response#credentials자산 목록에 없는 것은 스캔되지 않는다 — 상수도 PLC 사건이 알려 주는 OT 노출 관리
CISA가 2026년 7월 30일 상하수도 부문 PLC를 겨냥한 활동이 크게 늘었다며 인터넷에 노출된 OT를 즉시 분리하라고 권고했습니다. 권고문이 관찰한 행위는 침해가 아니라 비밀번호 변경으로 운영자를 잠그고 IP 주소를 바꿔 장비를 끊어 놓는 것이었고, 그 결과가 끓임 안내와 장기간의 수동 운전이었습니다. 이 권고문을 그대로 읽으면서, 정기 공격 표면 스캔에 잡히지 않는 셀룰러 모뎀 문제
2026-08-09 · 18 분 읽기 #security#ot#ics#plc#cisaAI가 6월 한 달에 2년치 크롬 버그를 잡은 방법 — 1,072개라는 숫자를 읽는 법
구글이 2026년 7월 30일 발표한 내용에 따르면 6월에 나온 크롬 149와 150 두 버전에서만 1,072개의 보안 버그를 고쳤고, 이는 지난 2년간 23개 마일스톤에서 고친 1,036개를 넘습니다. 13년간 살아 있던 샌드박스 탈출 버그도 여기서 나왔습니다. 이 글은 헤드라인 대신 메커니즘을 봅니다 — 2023년 LLM 기반 퍼즈 타깃 생성에서 2024년 Naptime, 2025년 Bi
2026-07-31 · 23 분 읽기 #ai#security#chrome#fuzzing#vulnerabilitySQL 인젝션과 파라미터 바인딩 — ORM을 써도 뚫리는 지점들
SQL 인젝션 대응책으로 가장 먼저 검색되는 것은 이스케이프 함수지만, 정답은 파라미터 바인딩입니다. 이스케이프는 값을 문자열 리터럴 안에서 안전하게 만들려는 시도이고, 바인딩은 값이 SQL 텍스트에 아예 들어가지 않게 만드는 구조적 분리이기 때문입니다. 이 글은 프리페어드 스테이트먼트가 서버에서 실제로 어떻게 파싱되고 실행되는지 로그로 확인하고, ORM을 쓰는데도 뚫리는 세 가지 지점과 O
2026-07-26 · 26 분 읽기 #security#sql#database#orm#python컨테이너 이미지 취약점 스캔 결과 읽는 법 — Critical 수백 개를 0으로 만드는 실제 방법
이미지 스캐너를 처음 돌리면 취약점 수천 건이 나오고 그중 상당수가 Critical입니다. 이 리포트를 그대로 팀에 던지면 아무 일도 일어나지 않습니다. 이 글은 스캐너가 실제로 하는 일이 설치된 패키지 목록과 CVE 데이터베이스를 대조하는 것뿐이라는 사실에서 출발해, 벤더 백포트 패치 때문에 생기는 오탐과 배포판 보안 권고를 참조해야 하는 이유, 애플리케이션 코드의 취약점은 애초에 보이지
2026-07-26 · 21 분 읽기 #security#container#docker#trivy#kubernetes인증과 인가, 그리고 IDOR — 로그인은 정상인데 남의 데이터가 보이는 이유
실제 데이터 유출 사고의 대부분은 인증이 아니라 인가에서 발생합니다. 로그인은 정상적으로 통과했는데 URL의 ID만 바꾸면 다른 사용자의 리소스가 그대로 반환되는 IDOR가 대표적입니다. 이 글은 인증과 인가의 경계를 코드 수준에서 구분하고, 순차 ID를 UUID로 바꾸는 것이 왜 해결책이 아니라 완화책에 불과한지 정확히 설명합니다. 인가 검사를 컨트롤러마다 흩어 놓으면 반드시 빠지는 곳이
2026-07-26 · 26 분 읽기 #security#authorization#idor#api#multi-tenant의존성 공급망 보안 — 락파일이 막아 주지 않는 것들
package.json에 직접 적은 패키지는 열몇 개인데 실제로 설치되는 것은 천 개가 넘습니다. 이 글은 전이 의존성이 왜 직접 의존성보다 위험한지, 락파일의 무결성 해시가 재현성은 보장하지만 악성 코드는 전혀 막지 못하는 이유를 실제 락파일 항목으로 설명합니다. 타이포스쿼팅과 의존성 혼동 공격이 성립하는 조건과 스코프 고정, 인덱스 우선순위 설정으로 막는 법, postinstall 스크립
2026-07-26 · 23 분 읽기 #security#supply-chain#npm#sbom#ciTLS 핸드셰이크와 인증서 오류 해독 — 브라우저는 되는데 curl은 실패하는 이유
브라우저에서는 자물쇠가 정상으로 뜨는데 curl과 서버 사이드 호출만 인증서 오류로 실패하는 상황은 서버 설정 문제입니다. 브라우저는 누락된 중간 인증서를 AIA 확장으로 직접 내려받지만 OpenSSL 계열 클라이언트는 그러지 않기 때문입니다. TLS 1.3 핸드셰이크를 메시지 순서로 읽는 법, SNI가 없을 때 벌어지는 일, 체인 검증이 끊기는 지점, 그리고 unable to get loc
2026-07-26 · 23 분 읽기 #network#tls#ssl#openssl#security.gitignore가 작동하지 않을 때 — 원인 1위와 패턴 규칙 정독
무시 목록에 분명히 적었는데 파일이 계속 올라오는 이유는 대부분 하나입니다. 이미 추적 중인 파일에는 무시 규칙이 적용되지 않습니다. 이 글은 인덱스에서 빼는 정확한 명령과 그 명령이 동료의 작업 디렉터리에서 파일을 지운다는 부작용, 어느 규칙이 범인인지 Git에게 직접 물어보는 check-ignore 사용법과 추적 중인 파일에서는 아무것도 출력하지 않는 함정, 선행 슬래시와 후행 슬래시와
2026-07-26 · 19 분 읽기 #git#gitignore#troubleshooting#security#version-control시크릿 관리, .env 파일만으로는 부족한 이유 — 환경변수가 새는 경로와 로테이션 설계
.env 파일을 .gitignore에 넣었다고 시크릿이 안전해지지는 않습니다. 프로세스 환경은 같은 호스트에서 /proc/PID/environ으로 그대로 읽히고, 크래시 리포트와 디버그 페이지와 CI 로그에 실려 나가며, 컨테이너 이미지 레이어에 영구히 남습니다. 이 글은 환경변수가 새어 나가는 실제 경로를 하나씩 보여주고, 시크릿이 이미 커밋된 경우의 대응 순서가 왜 히스토리 재작성이 아니
2026-07-26 · 27 분 읽기 #security#secrets#devops#vault#kubernetesJWT와 세션, 무엇을 언제 — 상태를 어디에 둘 것인가로 정리하는 인증 선택
JWT와 세션의 차이는 암호화나 성능이 아니라 인증 상태를 서버에 둘 것인가 클라이언트에 둘 것인가 하나입니다. 이 선택에서 즉시 무효화 불가능이라는 JWT의 근본 약점이 따라 나오고, 짧은 만료와 리프레시 토큰과 블랙리스트라는 대응책이 왜 결국 상태를 다시 불러들이는지가 설명됩니다. 토큰 저장 위치를 두고 벌어지는 localStorage의 XSS 노출과 httpOnly 쿠키의 CSRF 노출
2026-07-26 · 23 분 읽기 #web#jwt#session#authentication#securityOPA는 지금 누가 유지하는가 — Styra 팀 Apple 합류, 그 후 11개월의 검증 가능한 기록
2025년 8월 20일 OPA 창시자들과 Styra 팀원 다수가 Apple에 합류한다는 공지가 나왔고, 커뮤니티에는 "Apple이 OPA를 인수했다"는 소문이 돌았습니다. 1차 소스로 확인하면 실체는 다릅니다 — 회사나 자산을 인수했다는 발표는 어디에도 없고, 사람들이 이직했으며, OPA는 CNCF 졸업 프로젝트로 남았습니다. 이 글은 그 공지의 정확한 문구, 이후 11개월 동안 실제로 일어
2026-07-17 · 21 분 읽기 #security#opa#authorization#open-sourceOpenBao는 Vault에서 실제로 얼마나 갈라졌나 — v2.6 네임스페이스 봉인까지, 릴리스 노트로 확인한 분기점
OpenBao v2.0.0 GA(2024-07-17)로부터 정확히 2년이 지났고, 사흘 전에는 v2.6.0이 나왔습니다. 이 글은 "BUSL 배신" 대 "지속가능성" 같은 진영 논리를 걷어내고, 양쪽 프로젝트의 릴리스 노트·체인지로그·커밋만으로 포크가 실제로 어디서 갈라졌는지 확인합니다. OpenBao는 Vault Enterprise 전용이던 네임스페이스를 v2.3.1에서 오픈소스로 가져왔고
2026-07-17 · 19 분 읽기 #security#open-source#devops#licensing