docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
This commit is contained in:
Antigravity Agent
2026-07-05 00:33:48 +09:00
parent 1cfd3bbb56
commit 9148c358d0
6455 changed files with 1 additions and 86875 deletions
@@ -0,0 +1,132 @@
---
id: security-auth-authz-patterns
title: Authentication vs Authorization 패턴
category: Coding
status: draft
source_trust_level: B
verification_status: conceptual
created_at: 2026-05-09
updated_at: 2026-05-09
tags: [security, auth, authz, rbac, abac, vibe-coding]
tech_stack: { language: "TypeScript", applicable_to: ["Backend"] }
applied_in: []
aliases: [RBAC, ABAC, ReBAC, policy, permissions]
---
# Authentication vs Authorization
> **Authn = "누구냐"** (token 발급), **Authz = "뭘 할 수 있냐"** (각 요청마다). 둘을 같은 코드에 섞으면 사고. Authz 는 **resource-aware**(이 사용자가 이 자원에 접근 가능한가) 가 핵심.
## 📖 핵심 개념
- 인증 (authn): 로그인, MFA, SSO. JWT / 세션.
- 인가 (authz): 권한 체크. 매 요청.
- 모델:
- **RBAC**: role → permission. "admin can edit anything".
- **ABAC**: 속성 기반. "user.dept === resource.dept".
- **ReBAC**: 관계 기반 (Google Zanzibar). "user owns / shares / member of".
- 대부분 RBAC + 일부 ABAC 조합.
## 💻 코드 패턴
### 인증 미들웨어
```ts
async function authenticate(req: Request): Promise<User> {
const auth = req.header('authorization');
if (!auth?.startsWith('Bearer ')) throw new UnauthorizedError();
const token = auth.slice(7);
const payload = jwt.verify(token, env.JWT_SECRET);
return await db.users.find(payload.sub) ?? throw new UnauthorizedError();
}
app.use(async (req, res, next) => {
try { req.user = await authenticate(req); next(); }
catch (e) { res.status(401).json({ error: 'unauthorized' }); }
});
```
### Authz — 자원 단위 (resource-aware)
```ts
async function canEditOrder(user: User, orderId: string): Promise<boolean> {
const order = await db.orders.find(orderId);
if (!order) return false;
if (user.role === 'admin') return true;
if (order.userId === user.id) return true;
return false;
}
app.put('/api/orders/:id', async (req, res) => {
if (!await canEditOrder(req.user, req.params.id)) {
return res.status(403).json({ error: 'forbidden' });
}
// ...
});
```
### Policy 패턴 — 별도 모듈
```ts
// policies/order.ts
export const OrderPolicy = {
read: (user: User, order: Order) => user.id === order.userId || user.role === 'admin',
edit: (user: User, order: Order) => user.id === order.userId && order.status === 'pending',
delete: (user: User, order: Order) => user.role === 'admin',
};
// 사용
if (!OrderPolicy.edit(req.user, order)) return res.status(403).end();
```
### Casl / oso — 라이브러리
```ts
import { AbilityBuilder, createMongoAbility } from '@casl/ability';
function defineAbility(user: User) {
const { can, build } = new AbilityBuilder(createMongoAbility);
can('read', 'Order'); // 모든 사용자
can('manage', 'Order', { userId: user.id }); // 본인 거
if (user.role === 'admin') can('manage', 'all');
return build();
}
const ability = defineAbility(req.user);
if (!ability.can('update', order)) return res.status(403).end();
```
### Open Policy Agent (OPA) — 정책 외부화
```rego
# policy.rego
allow {
input.user.role == "admin"
}
allow {
input.action == "read"
input.user.id == input.resource.owner_id
}
```
복잡한 정책은 OPA 같은 정책 엔진. 코드와 분리, 감사 가능.
## 🤔 의사결정 기준
| 복잡도 | 도구 |
|---|---|
| 2-3 role, 단순 CRUD | role check 인라인 |
| 자원 단위 권한 (본인 / admin) | Policy 함수 |
| 다양한 조건 (시간, 부서, 단계) | Casl / oso / OPA |
| Multi-tenant + 공유 | ReBAC (SpiceDB / Cerbos) |
| 외부 API 호출 권한 | OAuth scopes |
## ❌ 안티패턴
- **인증 = 인가 가정**: "로그인됨 = 모두 가능". resource-aware authz 필수.
- **role check 만**: "admin 이면 다 OK". multi-tenant / 사용자 데이터 모두 노출 위험.
- **client-side authz**: 메뉴 숨겨도 API 직접 호출 가능. 항상 서버.
- **policy 가 코드 곳곳에**: 일관성 없음. 한 모듈에 모음.
- **권한 거부 시 404 vs 403 일관성 없음**: 404 면 자원 존재 여부 누설 안 됨. 정책에 따라.
- **owner check 안 함**: `/api/orders/:id` 가 본인 거인지 확인 없이 반환. IDOR 사고.
- **RBAC 만 + 동적 조건 안 됨**: "결제 완료 전엔 수정 가능, 후엔 admin 만" 같은 ABAC 필요.
## 🤖 LLM 활용 힌트
- "인증 vs 인가 분리. 매 mutation endpoint 에 resource-aware check" 강제.
- Policy 모듈 패턴 권장.
## 🔗 관련 문서
- [[Web_JWT_Patterns]]
- [[Security_CSRF_Patterns]]
- [[Security_Input_Validation]]