[OSTEP] 스터디 22주차 Security Access

1. 도입우리는 우리의 보안 목표가 무엇인지 알고 있고, 우리가 강제하고자 하는 보안 정책에 대한 최소한의 일반적인 감을 잡았으며, 우리의 정책을 위반할 수도(혹은 위반하지 않을 수도) 있는 다양한 시스템 서비스를 요청하는 주체가 누구인지에 대한 증거를 가지고 있다. 이제 우리는 그 정보를 가져와서 소프트웨어가 우리를 대신해 수행할 수 있는 실질적으로 실행 가능한 무언가로 전환해야 한다.여기에는 두 가지 중요한 단계가 있다:해당 요청이 우리의 보안 정책 내에 적합한지 판단한다.적합하다면 작업을 수행하고, 그렇지 않다면 작업이 수행되지 않도록 확실히 보장한다.첫 번째 단계를 일반적으로 접근 제어(Access Control)라고 부른다. 우리는 어떤 시스템 자원이나 서비스가 어떤 주체에 의해, 어떤 방식으로..

• format_list_bulleted Deep Dive/OS
• · 2026. 2. 3.
• textsms

[OSTEP] 스터디 21주차 Security

OSTEP의 최신? 버전에 포함된 Security를 학습하기로 스터디에서 결정했다. 내가 가진 책에는 포함된 내용이 아니라 https://pages.cs.wisc.edu/~remzi/OSTEP/ PDF에서 제공하는 자료로 학습을 진행한다.1. 복숭아로 이해하는 보안의 3대 요소 (CIA)OSTEP에서는 보안의 3대 요소를 복숭아에 비유해 설명한다. 우리가 가진 소중한 자원을 복숭아라고 생각한다면 보안은 다음 세가지를 지키는 것이라고 한다.1. 기밀성 (Confidentiality)비유: 내가 잠시 고개를 돌린 사이, 누군가 내 복숭아를 훔쳐가는 것을 원치 않는 것.정의: 오직 인가된 사용자나 시스템만이 자산에 접근할 수 있도록 보장하는 것.컴퓨터에서: 개인의 비밀번호, 신용카드 정보, 민감한 개인 파일 ..

• format_list_bulleted Deep Dive/OS
• · 2026. 1. 20.
• textsms

[OSTEP] 스터디 20주차 Andrew File System (AFS)

분산 파일 시스템의 고전인 NFS가 '단순함'을 택했다면, 카네기 멜론 대학교(CMU)에서 개발한 AFS는 수천 대의 클라이언트를 수용할 수 있는 '확장성(Scalability)'에 모든 사활을 걸었다.1. AFS의 핵심 설계 철학: 확장성 (Scalability)NFSv2는 클라이언트가 늘어날수록 서버에 "이 파일 최신이야?"라고 묻는 요청(GETATTR)이 폭증하여 서버가 마비되는 문제가 있었다. AFS 연구진은 다음 두 가지 질문에 집중했다."어떻게 하면 서버 한 대가 더 많은 클라이언트를 감당할 수 있을까?""클라이언트가 최대한 스스로 일을 처리하게 할 순 없을까?"2. 전체 파일 캐싱 (Whole-file Caching)AFS의 가장 큰 특징은 데이터 접근 방식입니다. 블록 단위로 가져오는 NF..

• format_list_bulleted Deep Dive/OS
• · 2026. 1. 13.
• textsms

[OSTEP] 스터디 19주차 Part.2 : 네트워크 파일 시스템(NFS)

분산 파일 시스템은 여러 대의 머신이 하나의 파일 시스템을 함께 쓰는 것을 목표로 한다. 한 머신에서 보던 파일과 디렉터리를 다른 머신에서도 같은 방식으로 접근하게 만들어 “어디서 접속하든 같은 파일을 쓰는 환경”을 제공한다.이 방식의 가장 큰 가치는 공유에 있다. 파일이 특정 클라이언트의 로컬 디스크에 갇히지 않고 서버 쪽에 놓이므로, 여러 클라이언트가 같은 데이터를 기준으로 작업하게 된다. 결과적으로 팀 단위 작업이나 여러 머신을 오가며 일하는 환경에서 데이터가 흩어지지 않는다.운영 측면에서도 이점이 생긴다. 데이터가 서버에 모이므로 관리가 중앙집중화된다. 백업 같은 작업을 모든 클라이언트에서 각각 처리하지 않고, 소수의 서버를 대상으로 수행하게 된다.보안 측면의 동기도 존재한다. 데이터가 저장된 서..

• format_list_bulleted Deep Dive/OS
• · 2026. 1. 6.
• textsms

[OSTEP] 스터디 19주차 Part.1 : 분산 시스템

분산 시스템은 전 세계의 구조를 바꿨다. 웹 브라우저가 지구상 어딘가에 있는 웹 서버에 접속하면 클라이언트/서버 분산 시스템이라는 구조에 한 구성원이 된다. Google이나 Facebook의 웹 서비스를 사용한다는 것은 하나의 기계를 사용하는 것이 아니다. 수천대로 이루어진 기계들이 사이트의 특정 서비스를 제공하기 위해서 서로 협력하고 있다.1. 분산 시스템의 등장 배경 (Introduction)분산 시스템은 여러 대의 독립된 컴퓨터가 네트워크로 연결되어, 사용자에게는 마치 하나의 시스템처럼 보이게 하는 소프트웨어 모음이다. 핵심 과제는 '어떻게 하면 신뢰할 수 없는 부품(메시지 손실, 기기 장애 등)을 가지고 신뢰할 수 있는 시스템을 구축할 것인가?'에 있다.분산 시스템의 핵심 사안은 실패와 고장의 극..

• format_list_bulleted Deep Dive/OS
• · 2026. 1. 6.
• textsms

클린아키텍처 2편: ‘안쪽은 바깥을 몰라야 한다’

백엔드 개발에서 변경은 피할 수 없다. 비즈니스가 바뀌면 도메인과 유스케이스가 함께 바뀌는 건 자연스럽다. 문제는 그 반대다. 비즈니스 규칙은 그대로인데, DB/프레임워크/외부 SDK 같은 ‘디테일’ 변화가 핵심 로직까지 밀고 들어오면서 수정 범위가 폭발하는 순간이 있다. 이 글은 그 폭발의 원인을 “레이어”가 아니라 의존성 방향으로 설명하는 원칙, 즉 Dependency Rule(의존성은 안쪽으로만 흐른다) 하나에만 집중한다. 그럼 여기서 말하는 ‘의존성’은 정확히 무엇일까? 자바에서는 특히 import/타입 참조로 이 규칙이 깨지기 쉽다.Dependency Rule이 말하는 ‘의존성’의 정확한 의미클린 아키텍처에서 말하는 “의존성”은 추상적인 분위기 용어가 아니다. 특히 자바에서는 의존성이 꽤 구체적..

• format_list_bulleted Deep Dive/아키텍처
• · 2026. 1. 3.
• textsms