1번
- 인증과 인가의 차이에 대해 설명해 주세요.참고자료 https://www.okta.com/kr/identity-101/authentication-vs-authorization/
2번
- 세션에 대해서 모르는 사람한테 설명하듯 간단하게 설명해 주세요.3번
- 세션과 쿠키 그리고 토큰 인증 방식에 대해 설명해 주세요.4번
- 세션과 토큰 인증 방식 중 각각의 장단점을 말씀해 주세요.출처: https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens
5번
- HTTP와 HTTPS 각각에 대해 설명하고둘의 차이점을 말씀해 주세요.6번
- HTTPS의 동작 방식을 설명해 주세요.HTTPS는 대칭키 암호화와 비댕칭키 암호화를 모두 사용하여 빠른 연산 속도와 안전성을 모두 가지고 있음.
HTTPS 연결과정(Hand-Shaking)에서는 먼저 서버와 클라이언트 간에 세션키를 교환한다. 여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 간의 교환에는 빠른 연산속도가 필요하므로 세션키는 대칭키로 만들어진다.
이 세션키를 클라이언트와 서버가 대칭키로 교환한다.
처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 대칭키가 사용되는 것이고 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것이다.
실제 HTTPS 연결과정이 성립되는 흐름
7번
- OAuth 2.0의 워크플로우에 대해서 설명해 주세요.8번
- Spring Security의 인증(Authentication) 처리 흐름에 대해 설명해 주세요.사용자가 로그인 정보와 함께 인증 요청을 합니다. 이 요청을 AuthenticationFilter가 요청을 가로채고, 가로챈 정보를 통해 UsernaemPasswordAuthenticationToken의 인증용 객체를 생성합니다. Authuenticion Manager의 구현체인 ProviderManger에게 생성한 UssernamePasswordToken 객체를 전달합니다. AuthenticationManger는 등록된 AuthenticationProvider를 조회하여 인증을 요구합니다. Provider는 UserDetials를 넘겨받고 사용자 정보를 비교합니다. 인증이 완료되면 권한등의 사용자 정보를 담은 Authentication 객체가 반환 됩니다. Authentication 객체를 SecurityContext에 저장합니다.
인증 절차는 실제로 이러한 흐름을 진행된다고한다.
이제 본격적으로 인증이 어떠한 과정으로진행되는지 처리 순서에 대한 흐름을 알아보자.
9번
- Spring Security의 인가(권한 부여, Authorization) 처리 흐름에 대해 설명해 주세요.Spring Security에서 권한 부여를 위해 authiztion필터 클래스를 이용해 처리합니다. 권한 부여필터는 먼저 Securtiy Context Holder로 부터 Authenitcation을 획득합니다. 획득한 인증과 HTttp 서블렛 리퀘스트를 매니저에게 전달합니다. 매니저는 구너한 부여 처리를 총괄하는 매니저 역할을 하는 인터페이스이고, 리퀘스트 매쳐 딜리게이팅 어써리제이션 메니저는 AuthriztionManger를 구현하는 구현체 중에 하나이빈다. RequestMatherDeligatingAuthizaionManger는 리퀘스트 메쳐 평가식을 기반으로 해당 평가시에 매치되는 메니저에서 권한 부여 처리를 위임하는 역할을 하며, 내부에서 매치되는 구현클래스가 있다면 해당 매니저를 구현 클래스가 사용자의 권한을 체크합니다. 적절하면 다음 요청 프로세슬를 이어가고, 아니라면 AcesssDeninedExpetion이 던져 ㄷExcetption Translateiton Filter가 입세션 처리를 합니다.
AuthorizationFilter
Spring Security에서는 권한 부여를 위해AuthorizationFilter
클래스를 이용해 처리를 한다.
AuthorizationFilter
입니다.AuthorizationFilter
는 먼저 SecurityContextHolder로 부터 Authentication을 획득합니다.AuthorizationManager
에게 전달합니다.AuthorizationManager
는 권한 부여 처리를 총괄하는 매니저 역할을 하는 인터페이스이고, RequestMatcherDelegatingAuthorizationManager
는 AuthorizationManager
를 구현하는 구현체 중 하나입니다. RequestMatcherDelegatingAuthorizationManager
는 RequestMatcher 평가식을 기반으로 해당 평가식에 매치되는 AuthorizationManager
에게 권한 부여 처리를 위임하는 역할을 합니다. ⭐ RequestMatcherDelegatingAuthorizationManager
가 직접 권한 부여 처리를 하는 것이 아니라 RequestMatcher
를 통해 매치되는 AuthorizationManager
구현 클래스에게 위임만 합니다.RequestMatcherDelegatingAuthorizationManager
내부에서 매치되는 AuthorizationManager
구현 클래스가 있다면 해당 AuthorizationManager
구현 클래스가 사용자의 권한을 체크합니다AccessDeniedException
이 throw되고 ExceptionTranslationFilter가 AccessDeniedException
을 처리하게 됩니다.10번
- Filter가 무엇인지 설명하고 Filter Chain의 동작에 대해 설명해 주세요.서블릿 필터는 자바에서 제공하는 API이며, javax.servlet 패키지에 인터페이스 형태로 정의되 있습니다. 필터 인터페이스를 구현한 서블릿 필터는 웹 요청을 가로채어 전처리를 할 수 있으며, 또한 엔드포인트에서 요청처리가 끝난 후 전달되는 응답을 클라이언트에게 전달하기 전에 후처리를 할 수 잇습니다. 서블릿 필터는 하나 이상의 필터들을 연결해 필터 체인을 구성할 수 있습니다. 각각의 필터들이 doFilter()라는 메서드를 구현해야하며, doFilter()매서드 호출을 통해 필터 체인을 형성하게 됩니다.
출처 https://urclass.codestates.com/content/3cbfcde0-c4a0-4a24-a45c-2b6b2c837531?playlist=2337
13번
- CI/CD가 무엇이라고 생각하시나요? CI와 CD의 차이점이 무엇인지 설명해 주세요.1차
요? CI와 CD의 차이점이 무엇인지 설명해 주세요.
CI/CD는 애플리케이션 개발 단계를 자동화 하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법입니다. CI는 개발바를 위한 자동화 프로세스인 지속적 통합 continuous integartion의 약자입니다. 지속적인 통합이 제대로 구현되면 애플리케이션코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합됩니다. CD는 지속적인 서비스 제공및 지속적인 배포를 의미하며 이 두 요어는 상호 교환하여 사용됩니다. 두 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이뤄지는지 설명하기 위해 별도로 사용되기도합니다. (차이점???)
전통적인 방식으로는 코드수정하고 배포하는데 까지 많은 시간이 소요되었다. 특히 QA테스팅에서 많은 버그가 발생되었다.
출처 https://blog.oursky.com/2019/08/19/how-to-build-cicd-pipeline/
CI/CD를 통해 지속적으로 통합·테스트·배포를 하고 이 흐름을 자동화하여 효율적으로 일을 처리할 수 있게 되었다.
출처 https://blog.oursky.com/2019/08/19/how-to-build-cicd-pipeline/
https://deveric.tistory.com/106
CI/CD는 약어로, 몇 가지의 다른 의미를 가지고 있습니다. CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미합니다. 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합됩니다. 따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 이 방법으로 해결할 수 있습니다.
CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환하여 사용됩니다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 합니다.
지속적인 제공이란 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포할 수 있습니다. 이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해 줍니다. 그러므로 지속적인 서비스 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 합니다.
지속적인 배포(또 다른 의미의 "CD": Continuous Deployment)란 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미합니다. 이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결합니다. 지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 서비스 제공의 장점을 활용합니다.
CI/CD는 지속적 통합 및 지속적 제공의 구축 사례만을 지칭할 때도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있습니다. 좀 더 복잡하게 설명하면 "지속적인 서비스 제공"은 때로 지속적인 배포의 과정까지 포함하는 방식으로 사용되기도 합니다.
결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미합니다.
이 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라집니다. 대부분의 기업에서는 CI를 먼저 추가한 다음 클라우드 네이티브 애플리케이션의 일부로서 배포 및 개발 자동화를 구현해 나갑니다.
Red Hat 전문가가 고객이 조직 차원에서 더 효율적으로 기존 애플리케이션을 현대화하고 새로운 애플리케이션을 구축하는 데 필요한 사례와 툴을 개발하고 문화를 조성하도록 지원합니다.
CI/CD 파이프라인의 마지막 단계는 지속적 배포입니다. 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 릴리스하는 지속적 제공의 확장된 형태인 지속적 배포는 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화합니다. 프로덕션 이전의 파이프라인 단계에는 수동 작업 과정이 없으므로, 지속적 배포가 제대로 이루어지려면 테스트 자동화가 제대로 설계되어 있어야 합니다.
실제 사례에서 지속적 배포란 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 클라우드 애플리케이션을 자동으로 실행할 수 있는 것을 의미합니다(자동화된 테스트를 통과한 것으로 간주). 이를 통해 사용자 피드백을 지속적으로 수신하고 통합하는 일이 훨씬 수월해집니다. 이러한 모든 CI/CD 적용 사례는 애플리케이션 배포의 위험성을 줄여주므로 애플리케이션 변경 사항을 한 번에 모두 릴리스하지 않고 작은 조각으로 세분화하여 더욱 손쉽게 릴리스할 수 있습니다. 그러나 자동화된 테스트는 CI/CD 파이프라인의 여러 테스트 및 릴리스 단계를 수행할 수 있어야 하기 때문에 많은 선행 투자가 필요합니다.
14번
- 본인이 구현해 본 CI/CD 배포 자동화 과정을 설명해 주세요.우선 첫번째 단계로 codepipeline을 이용해서 각 단계를 연결하는 파이프 라인을 구축합니다.
Source 단계에서 소스 코드가 저장된 github 리포지토를 연결하여 수정후 push하면 빌드 단계로 넘어가게 됩니다. code build 서비스를 이용해서 빌드 후 ec2인스턴스로 빌드된 파일 이 전달되고 이 결과 문이 객체 스토리지 S3버킷에 저장되면 deploy단계로 codeDeploy 서비스를 이용하여 EC2 인스턴스에 변경 사항을 실시간으로 반영하게 됩니다.
Source 단계
2. Build 단계
3. Deploy 단계
저도 직장인인데 백엔드 취준 병행중이거든요..! 좋은 취준 팁 얻고 갑니다! 다른 사람들은 어떻게 공부하는지 궁금할 때 가끔 블로그 찾아보고 있는데 도움이 많이 됩니다~! 혹시 저처럼 직장 병행하느라 시간 부족하신 분들은 저랑 같이 공부해보시면 어떨까요..ㅎㅎ 저도 많이 부족하긴 하지만, 현직자분들이 직접 저녁까지 1:1로 코칭해주시거든요..!
고민 중이신 분들 있다면 한 번 들어와서 보셔요..!https://zrr.kr/G5Hr
벨로그 트렌드에 떠서 구경하러 왔슴미다 ~~
주어졌던 질문들 중 대부분의 것들을 정리해 놓으셨군요 !
멋지십니다 👍