hee-ya07 님의 블로그

0. 대칭키 암호화와 비대칭키 암호화  대칭키 암호화 (Symmetric Encryption) 비대칭키 암호화 (Asymmetric Encryption) 암호화 및 복호화 방식 동일한 키로 암호화하고 복호화 공개키로 암호화하고 비공개키로 복호화 키 관리 - 키 관리가 매우 중요- 키 유출 시 위험 - 공개키는 자유롭게 배포 가능, - 비공개키는 보호 필요 연산 속도 - 빠름 - 느림 보안성 - 키 유출 시 보안 위험 있음 - 매우 안전 (공개키는 노출되어도 안전) 적합한 용도 - 대량 데이터 암호화- 빠른 통신 (클라이언트-서버 간) - 인증, 개인 정보 보호, - 1: N 통신 (단일 서버와 다수 클라이언트) 비대칭 암호화는 갑을 관계를 내포, 갑(비공개키)과 을(공개키) => 데이터 관..

0. 시작: WB의 엔진은 JS를 동작시키기 때문에 높은 자율성을 얻을 수 있게 되었지만, 트레이드오프로 많은 취약성을 가짐0.1 Origin과 SiteOrigin: Scheme + Host Name (Domain Name) + Port 으로 구성: Ex) https://api.KK.com:8080Site: Domain Name 중 SLD (Second-Level Domain) + TLD (Top-Level Domain) : Ex) api.kk.com or admin.kk.com다른 말로 정의하자면 TLD + 1 혹은 eTLD + 1 영역: TLD (Top-Level Domain) 에는 eTLD (유효 TLD) 개념이 존재Domainkk.comOriginhttps:// + kk.com + :8080Sit..

1. 웹 스토리지: WB의 클라이언트 사이드 저장소: HTML 5 표준 이후에 Cookie가 아닌 Storage를 저장소로 사용함Cookie VS Storage속성CookieStorage공통점WB에 저장됨WB간 공유 불가 저장 가능 용량4KB10MB목적WS에 반복적 전달을 위한 작은 정보WB만 사용 가능한 큰 정보만료만료 시간 설정 가능만료 시간 설정 불가범위지정된 Domain + path 만 유효지정된 Domain 내에서 유효보안WS에 Non-HTTP 요청 시, 노출-> 스트립트 접근 여부 제어 가능WB 내에서만 접근 가능-> 스크립트 접근 불가 스토리지의 종류종류Local StorageSession Storage차이점WB에 상관 없이 영원WB에 종속적 -> 브라우저 창이 닫히면 삭제공통점- 약 5MB..

보호되어 있는 글입니다.

1. Cookie1.1 Cookie: 사용자의 상태를 기억하는 목적(-> 세션과 같이 사용 X시, Stateless): 사용자가 웹 사이트 방문 시, WS가 WB에게 저장하는 작은 데이터(텍스트 형식 저장):: WB는 이후 같은 웹 사이트 방문 시, 자동으로 쿠키를 WS에 전송=> WS에서 제어 + WB에 저장 및 전송1.2 Cookie의 사용쿠키 설정- WS 헤더: set-cookie로 제어- WB 헤더: cookie로 전송사용 기준: Domain + Path === WB가 쿠키를 WS에 전송하는 기준- 사용 Path의 경우, / 이후로범위 특정 -> 단 / 하나만 정의 시 와일드 카드의 의미(*)- 사용 Domain 유의점- subDomain 정의 X호스트의 하위 도메인들은 모두 해당 쿠키 사용 가능..

1. Proxy: 클라이언트와 서버 사이에서 중계 역할을 하는 서버나 장비: 사용자와 인터넷 간의 연결을 중개하며, 주로 보안, 성능 향상, 네트워크 관리 등을 목적으로 사용목적- 보안 : IP 숨기기 or 프록시 서버를 방화벽으로 사용(프록시 방화벽)- 속도(캐시) : 동일 요청 시, 저장된 Cache 반환        => 전송 시간 절약, 외부 트래픽을 줄여 네트워크 병목 현상도 방지- ACL : 사이트 접근 범위 정책 정의 (Proxy Server 에 접속할 수 있는 범위를 설정하는 옵션)- Log / Audit : 리포트, 모니터링 (회사 내 직원의 인터넷/인트라넷 사용을 레포팅)분류: Forward Proxy | Reverse Proxy Forward Proxy: Client 측에 위치1) 클..

1. HTTP Cache 동작 원리- 캐시는 임시적인 저장이므로 실시간성 X, 하지만 준실시간성을 보장하고자 함- 재검증은 "주기"와 "기준"으로 판단1.1 HTTP Cache 재검증 기준Last-Modified (수정일) 낮은 정확도 - 텍스트 파일 수정 후, 다시 원상복구한 경우 수정일만 변경검사 방법 - If-Modified-Since : 바뀌었어? - If-Unmodified-Since : 안바뀌었어?ETag (고유값) 높은 정확도 - but, HTTP 1.0 혹은 1.1 호환성을 위해 위와 함께 사용검사 방법 - If-None-Match : 바뀌었어? - If-Match : 안바뀌었어?Last-Modified : 마지막 수정일(시간) 기반으로 캐시의 유효성 판단: 웹 서버가 Last-Modifi..

1. 등장 배경: WB는 매번 WS에 요청-> 응답, WS는 매번 WB의 요청에 값 반환 ==> 둘 다 바빠진다!    => 이전의 로드 응답 똑같다면 굳이 통신 해야할까?: WB or WS에 임시 저장소 == 캐시   => 데이터의 주인 == 서버이므로 헤더를 통해 서버에서 어디에 뿌릴지 관리2. Cache의 종류CacheHTTP CachePrivateShared=> public과 private Server CacheLocalGlobal 2.1 HTTP Cache  - HTTP Cache데이터를 캐시하는 곳- 저장 장소 지정 방식에 따라WBprivate 개인의 WB에 저장된 것only WbprivateProxyshared 중간 서버에 저장되서 다수의 WB에서 접근 가능WB + Proxy에 저장publi..

1. Infrastructure1.1 물리 서버자체적으로 구축한 데이터 센터 => On-Premise단점 => 고정 비용 + 직접 운영 관리- 건물 유지비용, 서버 구매비용, 유지보수 등 - 한번 구매, 설정하면 수요에 상관없이 계속 보유, 관리필요1.2 가상 서버(클라우드 서버)데이터 센터에서 임대 => 온디맨드 비용 + AWS가 대신 운영 관리(아마존은 신이야)장점- 간편한 설정- 고정되지 않은 유동적인 비용1.3 서버리스(Serverless)서버 구축 Xonly 상시 서버가 아닌 필요할 때마다 빌림1) 서버 필요 요청2) 서버 활성화(= 타 서버 대여)3) 작업 이후 서버 비활성화(= 서버 반납)요청 횟수에 따른 과금이기에 => 낮은 트래픽, 고메모리 필요시에 유용(= 호출 횟수는 적고, 작업의 필..

1.1 하드웨어: app(sw)가 구동되는 머신: 내부 자원(CPU + Memory) + 외부 자원(I/O)(네트워크 IO, 저장장치 IO, 마우스 키보드 등) 1.2 소프트웨어: 시스템 소프트웨어(OS) + 응용 소프트웨어-  시스템 SW: OS 운영체제(CPU의 자원 관리 - 응용 SW: 어플리케이션(=프로그램), shell  1.3 프로그램, 프로세스, 스레드프로그램- 파일, 코드 등의 정적인 상태프로세스- 프로그램이 자원을 할당 받아 활성화된 상태- 실행 단위가 상대적으로 크고,- 하나의 프로그램에는 하나의 프로세스만 존재- heap(바구니) + Stack(함수 호출)스레드- 프로세스 안의 작은 작업 단위- 실행 단위가 상대적으로 작고- 하나의 프로그램에 다수의 스레드 존재 가능- 프로세스와 공유..