새로운 프로젝트를 시작하면서 스프링 시큐리티 5.0을 적용하고 있다. 어떤 새로운 기능이 있는지 확인하기 위해서 참고문서(What’s New in Spring Security 5.0)를 살펴봤다. 새로운 기능이 추가되었는데 대략 다음과 같다.

Spring Security 5 새로운점

이 중에서 크게 관심을 끄는 항목은 '현대화된 비밀번호 인코딩' 항목이었다. 이전까지는 BcryptPasswordEncoder를 기본으로 단방향 암호화인코더로 사용해왔다.

PasswordEncoder passwordEncoder = new BcryptPasswordEncoder();

Spring Security’s PasswordEncoder interface is used to perform a one way transformation of a password to allow the password to be stored securely. Given PasswordEncoder is a one way transformation, it is not intended when the password transformation needs to be two way (i.e. storing credentials used to authenticate to a database). Typically PasswordEncoder is used for storing a password that needs to be compared to a user provided password at the time of authentication.

위의 내용을 구글번역기로 돌려보면

스프링 시큐리티의 PasswordEncoder 인터페이스는 패스워드를 단방향으로 변환하여 패스워드를 안전하게 저장할 수있게 해준다. PasswordEncoder는 편도 변환이며, 암호 변환이 양방향 (즉, 데이터베이스 인증에 사용되는 자격 증명 저장) 일 필요가있는 경우에는 제공되지 않습니다. 일반적으로 PasswordEncoder는 인증시 사용자가 제공한 암호와 비교해야하는 암호를 저장하는 데 사용됩니다.

대충 정리하면, 스프링 시큐리티에서 제공하는 PasswordEncoder는 사용자가 등록한 비밀번호를 단방향으로 변환하여 저장하는 용도로 사용된다. 그리고 시대적인 흐름에 따라서 점점 고도화된 암호화 알고리즘 구현체가 적용되어간다. 이런 과정에서 서비스에 저장된 비밀번호에 대한 암호화 알고리즘을 변경하는 일은 상당히 많은 노력을 요구하게 된다.

단방향의 변환된 암호를 풀어서 다시 암호화해야 하는데 그게 말처럼 쉬운 일은 아니다.

그래서 스프링시큐리티에서 내놓은 해결책이 DelegatingPasswordEncoder 다.

사용방법은 간단하다.

public class PasswordEncoderTest {

 

    private PasswordEncoder passwordEncoder;

 

    @Before

    public void setUp() throws Exception {

        passwordEncoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();

    }

 

    @Test

    public void encode() {

        String password = "password";

 

        String encPassword = passwordEncoder.encode(password);

 

        assertThat(passwordEncoder.matches(password, encPassword)).isTrue();

        assertThat(encPassword).contains("{bcrypt}");   (1)

    }

}
PasswordEncoderFactories.createDelegatingPasswordEncoder()로 생성한 PasswordEncoder는 BCryptPasswordEncoder가 사용되며 앞에 {id}로 PasswordEncoder 유형이 정의된다.

PasswordEncoderFactories.createDelegatingPasswordEncoder에 정의되어 있는 PasswordEncoder 종류를 살펴보면 다음과 같다.

public static PasswordEncoder createDelegatingPasswordEncoder() {

		String encodingId = "bcrypt";

		Map<String, PasswordEncoder> encoders = new HashMap<>();

		encoders.put(encodingId, new BCryptPasswordEncoder());

		encoders.put("ldap", new LdapShaPasswordEncoder());

		encoders.put("MD4", new Md4PasswordEncoder());

		encoders.put("MD5", new MessageDigestPasswordEncoder("MD5"));

		encoders.put("noop", NoOpPasswordEncoder.getInstance());

		encoders.put("pbkdf2", new Pbkdf2PasswordEncoder());

		encoders.put("scrypt", new SCryptPasswordEncoder());

		encoders.put("SHA-1", new MessageDigestPasswordEncoder("SHA-1"));

		encoders.put("SHA-256", new MessageDigestPasswordEncoder("SHA-256"));

		encoders.put("sha256", new StandardPasswordEncoder());

 

		return new DelegatingPasswordEncoder(encodingId, encoders);

	}

생성되는 암호화코드의 종류는 대략 다음과 같다.

{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
{noop}password
{pbkdf2}5d923b44a6d129f3ddf3e3c8d29412723dcbde72445e8ef6bf3b508fbf17fa4ed4d6b99ca763d8dc
{scrypt}$e0801$8bWJaSu2IKSn9Z9kM+TPXfOc/9bdYSrN1oD9qfVThWEwdRTnO7re7Ei+fUZRJ68k9lTyuTeUp4of4g24hHnazw==$OAOec05+bXxvuu/1qZ6NUR+xQYvYv7BeL1QxwRpY5Pc=
{sha256}97cde38028ad898ebc02e690819fa220e88c62e0699403e94fff291cfffaf8410849f27605abcbc0

{id}가 없는 비밀번호의 경우에는 다음과 같이 선언해서 확인작업이 가능하다.

@Test

public void 암호변환기ID가_없는경우는_다음과같이() {

    String password = "password";

    String encPassword = "$2a$10$Ot44NE6k1kO5bfNHTP0m8ejdpGr8ooHGT90lOD2/LpGIzfiS3p6oq";                       // bcrypt 

 

    DelegatingPasswordEncoder delegatingPasswordEncoder = (DelegatingPasswordEncoder) PasswordEncoderFactories.createDelegatingPasswordEncoder();

    delegatingPasswordEncoder.setDefaultPasswordEncoderForMatches(new BCryptPasswordEncoder());

 

    assertThat(delegatingPasswordEncoder.matches(password, encPassword)).isTrue();

}

DelegatingPasswordEncoder를 이용하면 암호화 알고리즘 변경에 대한 걱정은 크게 하지 않아도 되겠다. 사용 전략에 대해서는 코드를 살펴보고 각자가 판가름하기 바란다.

테스트 코드는 다음과 같다.


기존에 저장되어 있는 암호화된 비밀번호를 DelegatingPasswordEncoder에서 사용할 수 있도록 이전하는 작업은 간단하다.

$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

를

{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

처럼 앞에 {bcrypt}만 넣어주면 된다.

그 다음 단계에 대해서는 각자 고민해보자.

부연설명

PasswordEncoder 자체가 단방향 암호화를 목적으로 생성되었다. 보안상의 원인으로 DB에 저장된 비밀번호가 유출되지 않는다면 변환된 비밀번호 앞에 {id}가 붙는다고 해서 크게 문제가 되지는 않는다고 생각한다…​ 유출되었을 때는 문제가 될 수도 있으려나?

참고사항


저작자표시


Lenovo Thinkpad T470P 커스텀과 도크를 주문했는데, 도크가 먼저 도착했다. 하아...!!

3주를 꽉 채워서 배송될 기세다. ㅠㅅ-

언능와라. T470p.

개발환경을 맥에서 윈도우+리눅스 시스템으로 변경한다.
저작자표시

'logbook' 카테고리의 다른 글

[로그] 어느 봄날의 구직활동:: 졸지에 백수였다가 이제 예비 월급쟁이개발자  (6) 2018.04.09
[daily] Spring Camp 로고 초안  (0) 2018.02.22
[소개] 협업도구 Microsoft Team Services  (0) 2017.11.08
[월급쟁이개발자] 인수인계  (0) 2017.11.05
[daily] 괴리감  (1) 2017.07.11

지난 2018년 1월 17일 GS타워 12층에서 'Chaos Engineering Community' 첫번째 모임이 있었다. 그 내용을 간단하게 정리해본다.


문제인식

부하테스트 혹은 품질테스트 등의 정형화된 테스트만으로는 운영 중에 Microservice에서 발생하는 문제를 해결할 수 없다.

Chaos Engineering

'운영' 서비스의 각종 장애 조건을 견딜 수 있는 시스템의 신뢰성을 확보하기 위해 분산 시스템을 실험하고 배우는 분야

  • 적용단계

    1. 정상 동작을 나타내는 시스템의 측정 가능 통계치로 '정상 상태' 정의하기

    2. 정상 상태가 대조군과 실험군 모두에서 계속될 것이라고 가정하기

    3. 서버 장애, 하드 디스크 오작동, 네트워크 끊김 같은 실제 문제 변수 정의

    4. 대조군과 실험군 사이의 정상 상태 차이를 조사하여 가설 검증하기

  • 카오스 엔지니어링 고급 원칙

    1. 정상 상태 행동에 관한 가설 구축

    2. 현실 세계의 문제 시도하기

    3. 실제 운영환경에서 실험하기

    4. 자동화를 통한 지속적 실험

    5. 폭발 반경 최소화

      • 장애 발생범위 통제

      • Circuit breaker, Bulkheads(격벽, 피해 확산 막음), DITTO(Do Idempotent Things to Others)


  • 개발팀: 예상치 못한 애플리케이션 오류에 대한 사람들의 대처가 오히려 문제를 키우기도 함.

    • 급히 고쳐서 처리하겠다는 생각

    • 서비스를 잠시 중단하더라도 확실하게 처리하고 재발을 방지하자.

    • 개발팀이 신뢰받고 힘이 필요하다고 생각함

토론해볼 문제: 카오스 엔지니어링

  • Q: DevOps vs SRE(Site Reliability Engineering) vs Chaos?

  • Q: 서비스 중 장애유발에 의한 피해대응태도는?

  • Q: 클라우드와 마이크로 서비스는 필수적인가?

  • Q: 카오스를 적용하기 힘든 서비스 종류가 있는가?

  • Q: 개발자의 몫인가? 운영자의 몫인가 아니면 DevOps 의 몫인가?

정리

카오스 엔지니어링은 '클라우드'환경에서 '마이크로서비스(Microservice)' 아키텍처를 도입했을 때 서비스 운영 중에 발생할 수 있는 문제를 카오스 엔지니어링팀이 발생시키고 장애가 발생하면서 생기는 파장을 확인하여 이를 해결하여 서비스를 더욱 안정적으로 하는 것을 목표로 하고 있다.

이를 시도해보기 위해서는 '클라우드' + '마이크로서비스 아키텍처' + '규모' + '자원'이 가능해야 하지 않을까 하는 생각이 든다. 저것 중 한가지라도 부족하면 시도해보기 어려운 분야가 아닐까.

참고




저작자표시

'DevOps' 카테고리의 다른 글

AWS 서울리전(Seoul Region) 설립, 이제 시작  (0) 2016.01.08
아... 스프링 부트 프로젝트가 1.5.8 까지는 레파지토리에 하위 프로젝트들을 유지하는 형태였는데...

https://github.com/spring-projects/spring-boot/tree/v1.5.8.RELEASE

2.0.0에서는

https://github.com/spring-projects/spring-boot/tree/v2.0.0.M6/spring-boot-project

으로 spring-boot-project 디렉터리를 만드어서 거기에 몰아넣었구나....


`WebMvcAutoConfiguration` 의 경우

1.5.8.RELEASE 는 `org.springframework.boot.autoconfigure.web`

2.0.0.M6 는 `org.springframework.boot.autoconfigure.web.servlet`


패키지 경로가 변경되었다. @_@);

2.0 나오면 책에 걸어둔 소스코드 링크 변경해야하네...

책의 경로를... 뽑아낼 필요가 있겠어.

저작자표시

'Java > SpringBoot' 카테고리의 다른 글

[springboot] 스프링 부트를 이용하는 개발자가 빠지기 쉬운 착각  (0) 2018.04.22
[springboot] 2.0.0 release!! 출시  (0) 2018.03.02
[springboot] The temporary upload location [**/tmp/tomcat.*/work/Tomcat/localhost/ROOT]** is not valid  (2) 2017.10.27
[springboot] AWS Elastic Beanstalk NGINX 설정  (0) 2017.05.31
[springboot] AWS Beanstalk 에서 SpringBoot 에 사용할 환경변수 정의  (0) 2017.02.23

MS Team Services 는 IT팀에서 소스코드를 관리(작성된 코드를 리뷰하고 빌드하고 테스트하는 일련의 과정을 살펴보고 제어가능)하고 그와 관련된 내용을 정리할 수 있는 개발 플랫폼으로서 매력이 있어보인다. 개발 방식에 맞춰서 빌드방식을 지정할 수 있는 것으로도 보인다.


기능만 봐서는 ‘깃헙 + 컨플루언스(Wiki 역할) + 지라(이슈관리) + 젠킨스(CI) + 트렐로(or 깃헙 프로젝트 관리, 칸반)’ 의 기능을 아우를 수 있는 서비스가 아닐까 추측해본다(아직 제대로 안써봤다.).


스타트업이라면 https://bizspark.microsoft.com/ 에서 startup 으로 신청해서 이용해보면 좋을 듯 하다.




저작자표시

'logbook' 카테고리의 다른 글

[daily] Spring Camp 로고 초안  (0) 2018.02.22
[diary] 개발장비 업그레이드  (0) 2018.02.01
[월급쟁이개발자] 인수인계  (0) 2017.11.05
[daily] 괴리감  (1) 2017.07.11
[book]바딘Vaadin & 회계천재...  (0) 2017.06.12

+ Recent posts

티스토리툴바