안녕하십니까 선생님, 양질의 강의 항상 감사드립니다.AuthenticationManager와 AuthenticationProvider의 구성에 대해서 개념적으로 확인하고 싶은 것이 있어 질문 드립니다.AuthenticationProvider를 직접 구성하여 등록하지 않으면 기본적으로 DaoAuthenticationProvider, BasicAuthenticationProvider, RememberMeAuthenticationProvider 가 등록이 되는데, 직접 커스텀한 Provider를 등록 시 이 3개의 기본 Provider들은 자동 구성에서 제외 되는 것 인가요?만약 AuthenticationManger를 builder 혹은 직접생성(new)을 통해 생성한다면 기본 제공 되는 Provider들은 자동 구성에서 제외되는 것 인가요? 만약 그렇다면 AuthenticationManager는 직접 등록하고 싶은 Provider가 있을 때에만 생성하는 것 인가요?

현재 제 build.gradle은plugins { id 'java' id 'org.springframework.boot' version '3.5.0' id 'io.spring.dependency-management' version '1.1.7' } group = 'io.security' version = '0.0.1-SNAPSHOT' java { toolchain { languageVersion = JavaLanguageVersion.of(17) } } repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:spring-boot-starter-security' implementation 'org.springframework.boot:spring-boot-starter-web' testImplementation 'org.springframework.boot:spring-boot-starter-test' testImplementation 'org.springframework.security:spring-security-test' testRuntimeOnly 'org.junit.platform:junit-platform-launcher' } tasks.named('test') { useJUnitPlatform() } 같이 설정이 되어 있습니다. AntPathRequestMatcher, MvcRequestMatcher가 사용이 되지 않는다고 자동완성때 밑줄이 쳐져 있어서.requestMatchers("/manager/**").hasAuthority("ROLE_MANAGER") .requestMatchers("/admin/payment").hasAuthority("ROLE_ADMIN")이렇게 수정하였는데 맞게 수정 한 것인지 문의 드립니다.

terraform plan시 ch1/eks.tf 파일에서 오류가 발생합니다.ch1 git:(main) ✗ terraform plan╷│ Error: Unsupported block type││ on eks.tf line 23, in provider "helm":│ 23: kubernetes {││ Blocks of type "kubernetes" are not expected here. Did you mean to define argument "kubernetes"? If so, use the equals sign to assign it a value.╵소스를 아래와 같이 변경하였습니다.kubernetes = { .... exe = {...set = [ {name = "clusterName"value = var.ClusterBaseName }, {name = "serviceAccount.create"value = "true" }, {name = "serviceAccount.annotations.eks\\.amazonaws\\.com/role-arn"value = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/AmazonEKSTFLBControllerRole-${module.eks.cluster_name}" }, {name = "region"value = "ap-northeast-2" } ]커서에서 바이브코딩으로 바꿔서 문법에러는 안나는데 여전히 버전문제인지 해결이 안되네요. ch1 git:(main) ✗ terraform plan╷│ Error: Unsupported block type││ on eks.tf line 23, in provider "helm":│ 23: kubernetes {││ Blocks of type "kubernetes" are not expected here. Did you mean to define argument "kubernetes"? If so, use the equals sign to assign it a value.╵➜ ch1 git:(main) ✗ terraform initInitializing the backend...Initializing modules...Downloading registry.terraform.io/terraform-aws-modules/eks/aws 20.37.1 for eks...- eks in .terraform/modules/eks- eks.eks_managed_node_group in .terraform/modules/eks/modules/eks-managed-node-group- eks.eks_managed_node_group.user_data in .terraform/modules/eks/modules/_user_data- eks.fargate_profile in .terraform/modules/eks/modules/fargate-profileDownloading registry.terraform.io/terraform-aws-modules/kms/aws 2.1.0 for eks.kms...- eks.kms in .terraform/modules/eks.kms- eks.self_managed_node_group in .terraform/modules/eks/modules/self-managed-node-group- eks.self_managed_node_group.user_data in .terraform/modules/eks/modules/_user_dataDownloading registry.terraform.io/lablabs/eks-external-dns/aws 1.2.0 for eks-external-dns...- eks-external-dns in .terraform/modules/eks-external-dnsDownloading registry.terraform.io/terraform-aws-modules/iam/aws 5.39.0 for irsa-external-dns...- irsa-external-dns in .terraform/modules/irsa-external-dns/modules/iam-assumable-role-with-oidcDownloading registry.terraform.io/terraform-aws-modules/iam/aws 5.39.0 for irsa-lb-controller...- irsa-lb-controller in .terraform/modules/irsa-lb-controller/modules/iam-assumable-role-with-oidcDownloading registry.terraform.io/terraform-aws-modules/vpc/aws 5.21.0 for vpc...- vpc in .terraform/modules/vpcInitializing provider plugins...- Finding hashicorp/cloudinit versions matching ">= 2.0.0"...- Finding hashicorp/null versions matching ">= 3.0.0"...- Finding cloudposse/utils versions matching ">= 0.17.0"...- Finding hashicorp/aws versions matching ">= 4.0.0, >= 4.19.0, >= 4.33.0, >= 5.79.0, >= 5.95.0, < 6.0.0"...- Finding hashicorp/helm versions matching ">= 2.6.0"...- Finding hashicorp/kubernetes versions matching ">= 2.16.0"...- Finding hashicorp/time versions matching ">= 0.9.0"...- Finding hashicorp/tls versions matching ">= 3.0.0"...- Installing hashicorp/helm v3.0.2...- Installed hashicorp/helm v3.0.2 (signed by HashiCorp)- Installing hashicorp/kubernetes v2.37.1...- Installed hashicorp/kubernetes v2.37.1 (signed by HashiCorp)- Installing hashicorp/time v0.13.1...- Installed hashicorp/time v0.13.1 (signed by HashiCorp)- Installing hashicorp/tls v4.1.0...- Installed hashicorp/tls v4.1.0 (signed by HashiCorp)- Installing hashicorp/cloudinit v2.3.7...- Installed hashicorp/cloudinit v2.3.7 (signed by HashiCorp)- Installing hashicorp/null v3.2.4...- Installed hashicorp/null v3.2.4 (signed by HashiCorp)- Installing cloudposse/utils v1.30.0...- Installed cloudposse/utils v1.30.0 (self-signed, key ID ********)- Installing hashicorp/aws v5.100.0...- Installed hashicorp/aws v5.100.0 (signed by HashiCorp)Partner and community providers are signed by their developers.If you'd like to know more about provider signing, you can read about it here:https://www.terraform.io/docs/cli/plugins/signing.htmlTerraform has created a lock file .terraform.lock.hcl to record the providerselections it made above. Include this file in your version control repositoryso that Terraform can guarantee to make the same selections by default whenyou run "terraform init" in the future.Terraform has been successfully initialized!You may now begin working with Terraform. Try running "terraform plan" to seeany changes that are required for your infrastructure. All Terraform commandsshould now work.If you ever set or change modules or backend configuration for Terraform,rerun this command to reinitialize your working directory. If you forget, othercommands will detect it and remind you to do so if necessary.➜ ch1 git:(main) ✗ terraform plan╷│ Error: Unsupported block type││ on .terraform/modules/eks-external-dns/helm.tf line 41, in resource "helm_release" "this":│ 41: dynamic "set" {││ Blocks of type "set" are not expected here.╵╷│ Error: Unsupported block type││ on .terraform/modules/eks-external-dns/helm.tf line 49, in resource "helm_release" "this":│ 49: dynamic "set_sensitive" {││ Blocks of type "set_sensitive" are not expected here.╵╷│ Error: Unsupported block type││ on .terraform/modules/eks-external-dns/helm.tf line 57, in resource "helm_release" "this":│ 57: dynamic "postrender" {││ Blocks of type "postrender" are not expected here.╵➜ ch1 git:(main) ✗

제가 듣고 있는게 AWS core 인줄알았더니 network더라고요 ,,하하 질문이있는데 두개의 강의는 좀많이 겹쳐 보이는데 차이점이 먼가요?

안녕하세요 선생님 제가 AWS 프리티어인데요 실습후에 혹시 VPN과 subnet은 남겨도 ES2 같은 인스턴스들은 삭제해야 추가요금이 붙지 않을까요?아니면 삭제 안하고 남겨놔도될까요?그리구 이게 사실 손에 익어야 하는데 사실은 코드처럼 어떻게 실습해야 할지 감이 오지가 않아요.어떤 방법이 좋을까요 단순 반복 작업은 의미가 없다고 생각해서요,,, 팁을 주시면 감사하겠습니다... 

저는 그래도 최신버전으로 테스트 하면서 비교를 해가며 학습하는게 좋겠다 싶어 학습중입니다.현재 springboot 3.5으로 학습중이며 security는 6.3인것 같습니다.그런데 학습 중 바뀐부분이 있는것 같아 확인 부탁 드리고 자 글을 남깁니다. 아래 내용이 맞는지 알고 싶어요..ㅠㅠ 🍜 비유로 설명: "라면 공장"🥣 Spring Boot 3.2 (옛 구조)**HttpSecurityConfiguration**이 먼저 출근해요"물 끓이고, 면 넣고, 스프 넣고" 직접 다 해요마지막에 포장(= SecurityFilterChain)도 본인이 함즉, 한 사람이 보안 설정 전체를 다 하는 구조🍱 Spring Boot 3.5 (새 구조)**WebSecurityConfiguration**이라는 총괄 매니저가 먼저 출근이 사람이 여러 명의 담당자 (HttpSecurity 설정)에게 일을 시켜요그리고 포장은 SecurityFilterChain으로 조립해서 내보냄즉, 분업된 구조 — 공장은 커졌고, 매니저가 통제함 🔍 왜 이런 변화가 있었을까?이유설명설정이 너무 복잡해졌음HttpSecurityConfiguration 혼자 하다 보니 커지고 유지보수가 어려움커스터마이징이 어려웠음사용자 정의 체인 추가가 어렵고 제한적이었음다중 체인 지원 부족API별 다른 보안 적용이 힘들었음 (/api/**, /admin/**)새 구조가 더 유연SecurityFilterChain을 빈으로 만들면 순서, 조건, 분리 모두 명확해짐🧠 구조 비교 요약항목Spring Boot 3.2 (Security 6.2)Spring Boot 3.5 (Security 6.3)먼저 실행HttpSecurityConfigurationWebSecurityConfiguration중심 클래스HttpSecurityConfigurationWebSecurityConfiguration책임 방식거의 혼자 다 함분업 (매니저 + 여러 체인)구성 방식내부적으로 HttpSecurity 설정외부에서 SecurityFilterChain 등록유연성다중 체인 어려움다중 체인, 조건부 설정 매우 쉬움✅ 결론Spring Boot 3.2에서는 여전히 옛 구조(약간의 WebSecurityConfigurerAdapter 잔재)를 끌어와서→ HttpSecurityConfiguration이 보안 설정의 진입점 역할을 했고,Spring Boot 3.5에서는 완전 리팩토링된 구조라서→ WebSecurityConfiguration이 보안 설정의 시작점(매니저)이 되었어요.

VPC CIDR이 Minimum 이 /28인경우가 이해가안가서요,,,Class c 1바이트 마다 아래처럼 구성되어있다고치면,네트워크 | 네트워크 | 네트워크 | 호스트인데 지금 섭넷팅이 된거겠죠? /28이라하면?그러면 2의 사승 16만큼 사용 가능할테고,강의마지막을 보니 AWS는 아키테쳑에서 bit 5개가 예약이죠.질문은 왜이게 Minimum이 되나요?사실 2개의 호스트만 있어도 되지않나 해서 총 minimum이 /29이어도 되지 않나 생각해봤습니다. (사실 굳이 그럴필요도없지만요,,,)즉 2의 3승 8 -5 는 3개의 호스트로 네트워크가 가능하니까요?즉 섭넷은 2의 13승8192개로 호스트 3개씩 돌릴수있다고 생각하거든요,,같은 이유로 Maximum또한 궁금합니다.Class A는네트워크 호스트 호스트 호스트 인데그러면 8비트인데 이거는 AWS VPC의 범위밖이면 class A는 못쓰나요?

안녕하세요,  수업 내용을 보면 6:00 시간대의 수업자료를 보면 SecurityConfigurer에서 init(B Builder), configure(B builder)을 호출한다고 나와있습니다. 하지만, 실제 소스코드를 보면 아래와 같은데, 파라미터를 보면 Builder 타입이 아닌, 파라미터를 넘기지 않는 것을 확인할 수 있습니다.@Override protected final O doBuild() throws Exception { synchronized (this.configurers) { this.buildState = BuildState.INITIALIZING; beforeInit(); init(); this.buildState = BuildState.CONFIGURING; beforeConfigure(); configure(); this.buildState = BuildState.BUILDING; O result = performBuild(); this.buildState = BuildState.BUILT; return result; } }확인 부탁드려도 될까요?감사드립니다.

신용정보법에서 개인신용정보가 누설되었음을 알게 되었을 때 통지나 신고 시점이 강의에서는 5일 이내라고 되어있는데 신정법 시행령에서 해당 내용을 찾을 수 없었습니다. pdf 개념서에는 72시간 이내라고 되어있는데 72시간이내가 맞는 걸까요?

강의 마자막의 "개인정보처리자의 책임 및 의무" 동의없이 처리할수 있는 개인정보는처리항목 및 법적근거를 개인정보 처리방침에 공개해야함동의 없이 처리할수 있다는 입증책임은 개인정보처리자가 부담 이부분은 제 22조 3항의 내용이지만 관련 내용이라서 추가 설명하실걸로 이해하면 될까요?  강의 잘듣고 있습니다.

배달의 만족예시에 대해 질문드립니다.  이때 동의없이 개인정보를 제3자에게 제공하기 위해선연락처 뿐만 아니라 이름,주소도 모두 안전조치를 해서 3자에게 제공해야하지 않나요? 이름, 주소가 3자입장에서 꼭 필요하다면 안전조치를 연락처만 해도 되나요? 즉 제공되는 개인정보중에서 임의로 선택해서 안전조치를 해도 되나요?  

자동화된 결정의 판단 기준으로 "정당한 권한을 가진 사람의 실질적이고 의미있는 개입없이 완전히 자동화된 시스템에의해 결정이 이루어졌는지 여부" 라는 근거는 어디에 있나요?  개보법이나 시행령에는 없는거 같은데...

안녕하세요.먼저 강의 제작해주셔서 감사합니다!많은 도움 되고 있습니다. 메타 주석 부분에 사실 expression이 없어서 제가 이해하기로는 타입 추론으로 값을 넣는 것 같습니다.그럼 결국 @AuthenticationPrincipal에서도 expression이 없어도 동작하는게 맞을까요? 감사합니다.

안녕하세요"인가 설정 실시간 반영하기" 코드에서 동시 세션 제어 기능을 추가할려고 합니다.http.sessionManagement(session -> session .maximumSessions(1) .maxSessionsPreventsLogin(true) )위 코드를 추가한 후 REST 방식으로 로그인후 로그아웃을 하면 SessionRegistry의 principals 객체에 있는 정보가 삭제되지 않아 다시 로그인을 시도하면 인증오류가 발생합니다.로그아웃을 할 경우 SessionRegistry.removeSessionInformation(sessionId)가 호출되어 principals 정보가 삭제되어야 할 것 같은데 제가 잘못 이해하고 있는 지 궁금합니다. 

localhost:8080 에서 login 페이지로 넘어가고, 로그인을 하면, error?cutomerParam=y 주소로 넘어갑니다. 리다이렉트는 문제없이 잘 된거 같은데 어디서 에러가 생격서 savedRequest 객체에 error가 저장되는지 도통 모르겠네요;; 로그인 직후 network

안녕하세요, 궁금한점 이있는데 33~34 강의 편에서 보면 공격자가 세션 쿠키를 희생자의 브라우저에 삽입해서 희생자가 로그인하면 공격자도 희생자의 정보를 탈취하는 그런 내용의 강의가 있었는데요, 궁금한 점은 공격자는 왜 로그인 같은 기타 인증을 하지 않고 기본적으로 세션 쿠키가 생성이 되어있는걸까요? SessionCreation policy 가 always 가 아니고 if required 였던거 같은데 왜 이미 생성되어 있던 것인지 궁금합니다.

안녕하세요.와주 강의 잘 듣고 있습니다.과정 중 궁금한게 있는데요,wazuh 중앙서버에서 설정한 sysmon 정책을 에이전트로 배포할 수 있는 방법이 있을까요?현실적으로 에이전트 환경에서 일일이 sysmon 정책을 적용하게는 어려울 것 같아서요. 

✨ 질의 안내선수 지식이 부족하더라도 걱정하지 마세요. 강의를 통해 필요한 내용을 차근차근 배워나갈 수 있습니다.각 항목별 추천 자료를 통해 기본 지식을 탄탄히 하면 강의 내용을 더 깊이 있게 이해하고 활용할 수 있습니다.디스코드 또는 인프런으로 질문주시면 바로 답변드리겠습니다디스코드 채널 :https://discord.gg/uCQEnRaSMG안녕하세요.'04_Agent방식 Wazuh Sysmon 연계 구축하기 (Linux)'11:15 부분에서 sysmon -accepteula -i ./config.xml 명령어를 입력하면 아래처럼 오류가 발생합니다. 구글링으로 아래 방법을 알게 되어 시도해봤으나 그대로입니다. 혹시 해결 방안이 있을까요?$ wget -c https://ftp.gnu.org/gnu/glibc/glibc-2.29.tar.gz $ tar -zxvf glibc-2.29.tar.gz $ cd glibc-2.29 $ mkdir build $ cd build $ ../configure --prefix=/usr/local/glibc-2.29/build --disable-sanity-checks $ make $ sudo make install출처: https://sung-jae.tistory.com/4 [Dream Pocket:티스토리] 번외로, 올려주신 강의 영상이 도움이 많이 되고 있습니다. 감사합니다.

안녕하세요. 강의 잘 보고,듣고, 익히고 있습니다!customAuthenticationFilter관련 부분보다가 궁금증이 생겨서 질문 남깁니다. authenticationManager, authenticationProvider 로직을 SecuriyConfig의 필터가 아닌 일반 서비스 로직 내부에서도 똑같이 커스텀해서 사용이 가능한가요? (Contoller에서 dto로 받아서 서비스에서 id/pw 검증 후 이후 과정을 처리하는 그런 흐름이 가능한건지 궁금합니다) jwt 관련 로그인을 구현하려고 하는데, 전체적인 구조는 SpringSecurity의 맥락을 그대로 가져가고 싶은..생각입니다.

 HttpSecurity에서 가져오는 AuthenticationManagerBuilder와주입받는 AuthenticationManagerBuilder가 사로 다르지만 타입이 같아 메서드는 똑같을텐데 managerBuilder.authenticationProvider(new DaoAuthenticationProvider()); builder.authenticationProvider(new DaoAuthenticationProvider());후자일경우 수업 내용처럼부모 프로파이더에는DaoAuthenticationProvider() 가 들어가고providers 에는 커스텀과 익명 프로바이더 2개가 들어가는데요 전자 즉 직접 참조하는 AuthenticationManagerBuilder는부모 프로바이더는 null 인데 반해 기존 providers 에 생겨서 총 3개가되고있습니다 물론 실제 실행할때에는 똑같은 결과지만 함수authenticationProvider 은 public AuthenticationManagerBuilder authenticationProvider(AuthenticationProvider authenticationProvider) { this.authenticationProviders.add(authenticationProvider); return this; }인데 왜 각각의 작동이 다른지 궁금합니다