경계된 컨텍스트 : 하나 이상의 경계된 컨텍스트를 포함하는 마이크로서비스를 만들지 말아야 한다.
전체 컨텍스트를 하나의 마이크로서비스에 매핑할 수 있으면 더 좋다, 이는 컨텍스트가 실제로 경계되어 있음을
나타내는 것이다.

유비쿼터스 언어 : 마이크로서비스가 사용하는 언어가 유비쿼터스 언어임을 보장해야 하므로, 노출된 오퍼레이션과
인터페이스는 컨텍스트 도메인 언어로 표현된다.

컨텍스트 모델 : 비록 마이크로서비스가 제공하는 인터페이스에 노출되지 않는 엔티티라 하더라도, 마이크로서비스가
사용하는 모델은 경계된 컨텍스트 내에서 정의되야 하고, 유비쿼터스 언어를 사용해야 한다.
컨텍스트 매핑: 마지막으로 마이크로서비스의 의존성과 결합을 이해하기 위해 전체 시스템의 컨텍스트 매핑을 검토해야한다.

 * 마이크로서비스는 비즈니스 역량을 중심으로 모델링되며, 컨텍스트 매핑에서 보여주는 바와 같이 컨텍스트
도메인은 느슨하게 연결되며, 경계된 컨텍스트로서 단일 책임을 갖게 된다.
경계된 컨텍스트를 구현한 마이크로서비스는 구현을 쉽게 은닉할 수있으며, 자연히 격리되므로 독립적인 배포가 가능하다.


* 실행가능한 jar만들기

build/plugins 태그 아래에 POM을 수정


  true


spring application 설정에서 값 받아오기
@Value(value ="\${service.message.text}" //표현식 사용 "#{'\${service.message.text}' =='advance'}"
사용 $text

SERVICE.MESSAGE.TEXT="HELLO"


json 
직렬화 ‫SimpleObject("hi","kotlin")" 
복잡한 직렬화 ComplexObject(object1 = SimpleObject("more","complex"))
(data class ComplexObject(var object1 : SimpleObject? =null))

null 값 처리 어노테이션
@JsonInclude(Include.NON_NULL)
또는
spring.jackson.default-property-inclusion

'Spring' 카테고리의 다른 글

VS CODE (비쥬얼 스튜디오 코드에서) Spring boot 실행 (RUN)  (0) 2020.04.03
Spring 날짜 타입 변환  (0) 2019.06.24
Spring 동작원리  (0) 2019.02.27
HTTP Status 404 - /WEB-INF 에러  (0) 2019.02.25
Spring MVC 구성 요소  (0) 2019.02.23

#클라이언트 인증 (http 기본 인증)

http는 기본적으로 stateless (무상태)이다. stateless라서 세션을 유지하기 위해서 쿠기 메커니즘을 사용한다.

하지만 안드로이드나 IOS기기 또는 CURL 등 다양한 클라이언트들이 쿠키 메커니즘이 동작한다고 보장 할 수 없다.

세션을 유지하지 않고, 요청할 떄마다 인증 정보를 제시하고 사용자를 식별하면 된다.

서버에 요청할 때마다 Authorization 요청 헤더에 인증 정보를 담아서 보낸다. 

1. http 기본 인증 

Header : POST /v1/articles HTTP/1.1
HOST : localhost
Authiruzation : Basic 12389sfdjiookasdy9849sdui== -- base61_encode
Accept : application/json
Content-Type : application/json 

{ "title":"글",
  "content":"몰라요"
}


- 기본 인증의 한계 (여러 가지 보안 취약점을 가지고 있다.)

1. 아이디와 비밀번호를 클라이언트 애플리케이션에 저장해야 한다. 
   개인 컴퓨터면 문제가 되지 않지만 공용 기기라면 완전히 다른 얘기가 된다. 

2. 평문으로 되어 있다.
   네트워크단에서 탈취 할 수도 있다. 다른 네트워크 도구 뿐 아니라, 브라우저의 개발자 도구로도 헤더를 볼수 있다. 

* 암호화가 가능 ,https 프로토콜을 이용하여 해결 가능 , 인트라넷처럼 제한된 환경에서 http 기본 인증 가능



#JWT
클라이언트 서버
1.CreateToken{ID:xx PW:xx} ----------------------------------------> 2. Token 생성 및 Store (저장)
        4. Tocken 저장      <----------------------------------------- 3.  tocken 
5.  Authorization 요청 헤더에 토큰을 달아서 보낸다(API호출 등) ----> 6. 유효성 확인 후 결과 전송 ( API 응답 , 로그인 등) 
7.  result                      <----------------------------------------  result

* 60 ~ 120분 적당(?)

#cors 동일 출처 보안 정책 (브라우저에서 이를 막음)
SPA ex) react 3000 port --> node 5000 port 

기본적으로 프로토콜,호스트명,포트 아 같은 Same-Origin에서의 접근이 가능하지만 다른 도메인
Adomain.page1.html -> Adomain.page2.html   Same-Origin

Adomain.page.html  -> Bdomain.page.html     Cross-Origin

서버에서 허용하여 주는 것으로 해결



# 보안 정책
1.사용량 제한

    특정 클라이언트가 API를 과도하게 사용하면 다른 클라이언트가 피해를 본다. 그뿐만 아니라 사용량 제한은 디도스 공격, 사전 공격 등으로부터 서비스를 보호하기도 한다.
    그래서 지정한 시간 동안 요청할 수 있는 횟수를 제한하는 방법 

2.리소스 아이디 난독화

    auto_increment를 기본키로 사용할 경우, 서비스가 커지면 자동 증가 아이디도 공격의 대상이 될 수 있다. 

-API로 응답받은 리소스의 아이디로 다른 리소스를 탐색 할 수 있다, 하지만 인증이나 인가 기능이 막아준다.
-아이디 번호를 하나씩 올려가며 리소스 전체를 긁어 갈 수 있다.
-사용자 아이디를 하나씩 올려 가며 서비스의 전체 사용자 수를 예측할 수 있다.

UUID를 사용하거나, 난수를 사용한다 


#CSRF(사이트간 요청 위조)
악성코드 서버에서 발생

공격과정 
...

http://auction.com/changeUserAcoount?id=admin&password=admin" width="0" height="0">
...
위 옥션 사건을 예로 들어보자.

옥션 관리자 중 한명이 관리 권한을 가지고 회사내에서 작업을 하던 중 메일을 조회한다. (로그인이 이미 되어있다고 가정하면 관리자로서의 유효한 쿠키를 갖고있음)
해커는 위와 같이 태그가 들어간 코드가 담긴 이메일을 보낸다. 관리자는 이미지 크기가 0이므로 전혀 알지 못한다.
피해자가 이메일을 열어볼 때, 이미지 파일을 받아오기 위해 URL이 열린다.
해커가 원하는 대로 관리자의 계정이 id와 pw 모두 admin인 계정으로 변경된다.

위 공격과정 출처 : https://sj602.github.io/2018/07/14/what-is-CSRF/

해결방법 
1. referrer 검증 - 같은 도메인 상에서 요청이 들어오지 않으면 차단
2.csrf 토큰 - 랜덤한 수를 사용자의 세션에 저장하여 사용자의 모든 요청에 대하여 서버단에서 검증하는 방법
3. captcha 이용하여 cahtcha 이미지상의 숫자/문자가 아니면 해당 요청을 거부

#XSS 
악성코드 클라이언트에서 발생
사용자를 대상으로 한 공격이다.

ex) input에  를 넣어 보냄 
해결방법 
입력 값 제한
입력 값 치환
필터 사용 등

 


# 파일 첨부 기능 (파일 업로드)

* form http 폼 전송의 인코딩 타입을 멀티파트/폼 데이터(multipart/form-data)로 바꾸어야 한다. 이 속성을 추가하지 않으면 파일은 전송 되지않고, 파일 이름만 전송된다.

첨부파일 저장 파일 만들 경우, 권한 잘 적용하여야 하고 git에 올라가는걸 방지 하자.

사용자 업로드 후 form 전송 -> 유효성 체크(원하는 형식인지 (MIMES:jpg,zip....) -> 같은 이름의 파일을 여러번 올릴 수 있기 때문에 구분값 (스트링랜덤값?..)등 필요 
   


# 쿼리 캐싱

사용자가 어떤기능을 사용할떄 가장 느린 부분은 데이터베이스를 사용하는 부분이다. 이처럼 비용이 높은 곳을 더싼 저장소로 대체하는 행위를 캐싱이라고 한다.
캐시 저장소는 보통 키-값으로 구성된다. 파일일 수도 있고, 메모리일 수도있다. 데이터베이스 접근을 요하는 컨트롤러 메서드에 사용자 요청이 도달하면, 컨트롤러는 요청 정보를 
이용해서 캐시 키를 만든다. 캐시 키로 저장소를 조회해서 찾으면 그 값을 사용한다. 이것을 캐시 힛이라고한다.
캐시 키를 찾지 못하면, 그 결과를 데이터베이스에 저장한다. 이 작업을 캐시 미스, 캐시 필 이라고 한다. 

하지만 메모리 캐시를 저장소를 사용하면 파일 시스템에 접근하는 오버헤드까지도 줄일 수 있다 이를 위한 데이터베이스는 멤캐시,레디스 등이 있다.




   

+ Recent posts