(다시보기) 서버 접근제어의 새로운 패러다임, Okta Privileged Access

접근 권한이 필요한 시점에만 선택해서 승인받고 접속하여 사용할 수 있는 건가요?

기업에서 제로 트러스트 보안 기반의 클라우드 계정 관리와 접근 통제를 기업의 상황에 맞게 최적으로 하려는 경우 중점적으로 검토하고 점검해야 할 사항들에 대해서 질문드립니다

그렇다면 Okta Privileged Access는 ZTA의 적용 어플리케이션 이라 이해해도 되나요, 아니면 ZTA적용을 하지 않고 있는 상황에서도 독립 어플리케이션 으로 사용하는 것이라 봐야 하나요

멀티 클라우드 환경에서도 적용하여 사용되는 사례가 있는지요? 여러 CSP별 계정권한관리 설정이 다양한데 대부분 지원하는지 궁금합니다

독립 솔루션이라면 모든 access/transaction 에 대한 ZTA가 아닌 identification/ authorization 에 국한 된 것인가요

암호화시 그 암호키는 클라우드에 암호데이터와 함께 저장되는 것인지 아님 암호키는 어디에 저장되서 국정원 보안규정상 원격지에 암호화키를 저장해야 된다는 항목에 위배되지 않는것인가요?

Okta Privileged Access가 기존의 서버 접근 제어 방식과 비교했을 때 어떤 점에서 더 안전한가요?

기존의 옥타 제품과 차이점은 그러면 무엇인가요? 지금까지의 설명은 기존 인증 권한제어 제품과 유사해 보입니다.

옥타는 어떤 규정 준수를 위한 모델인가요?

오...

커스터마이제이션이 관리자에게 추가적 업무 뿐만아니라 임시해결책을 마련하는것이 까다로운데 이럴때 어떤 도움을 받을수있을까요?

Audit & session recording 의 경우 기존의 edr/xdr과 기능이 중복되지는 않나요

솔루션 도입 시 내부 전문인력이 있어야 하나요? 솔루션 도입을 위해 검토해야 할 사항들이 많을 것 같은데요. 솔루션 도입 및 시스템 구축 후에 사내 아이덴티티 전문가 및 CIAM 책임자가 있어야 하는것이 아닌지요?

리눅스에서 윈도우즈 서버로의 서버 이관 및 재구축시에 Okta Privileged Access 재설치 및 이관시에 절차나 구성, 사용법은 동일한가요?

서버에 접속 계정이 없고 접속신청 승인 시 계정생성, 권한생성/부여가 된다면 계정/권한관리는 Okta에서 관리한다고 보면 되나요? 그럼 접근로그 같은 감사증적은 Okta 만으로도 커버가 될지요?

[질문] 시스템 보안의 완성도를 높이기 위해서는(일원화된 보안정책과 관리의 편의성 , 통합 제로트러스트 전략 수립의 용이성) 계정 생성부터 접근 권한 제어 및 통제, 관리까지 총망라한 솔루션이 더욱 필요하다고 생각합니다. 소개해주시는 솔루션은 어떤지 문의드립니다.

1.최근 기능별, 영역별로 접근제어, 계정관리, 패스워드 관리 등 각각의 솔루션을 편리하고 안전하게 운영·관리하기 위해 통합되고 있다고 봅니다. Okta Privileged Access솔루션의 가장 핵심적인 기능은 무엇이고 Okta솔루션을 선택해야 하는 이유와 타사 대비 가성비는 어떤지 궁금합니다. 2.Okta Privileged Access솔루션이 적용된 국내 대표적 사례와 적용하는 과정에서 발생되었던 문제점들과 그 해결사례도 궁금합니다.

Cloud 환경에서 자동으로 증가 및 감소하는 서버 인스턴스에 대해 Okta의 접근 제어 방식이 어떻게 대응하나요?

Oauth 2.0에서 토큰의 수명을 짧게 설정하는 것과 차이가 있을까요

App 접근 통제 방식과 서버 접근 통제 방식에서의 핵심 차이점은 무엇인가요?

계정 패스워드는 일방향암호화로 저장되고 클라우드 상에 존재하는지요 보안사고등으로 암호가 누출되었을때도 원본암호는 안전한지 궁금합니다.

[질문] Okta Privileged Access 의 라이선스 구성과 과금 기준은 어떻게 되나요? SaaS 형태도로도 이용이 가능한가요?

Cloud 환경에서 자동으로 증가 및 감소하는 서버 인스턴스에 대해 Okta의 접근 제어 방식이 어떻게 대응하나요?

[질문] Okta Privileged Access의 차별점과 적용관련 이슈해결 노하우가 궁금합니다

사용자가 토큰을 발급받는 순간에 해커가 토큰을 갈취하는 경우에는 침입을 막을 방법이 없는 건가요?

Okta Privileged Access는 제로 트러스트 보안 모델과 어떻게 연관이 있나요?

[질문] Okta Privileged Access가 서버 접근에 대한 심플하고 안전한 방법을 제공함에 있어, 보안정책이나 도구는 어떻게 지원이 되고, 어떻게 기존이나 타 서비스 대비 안전, 즉, 보안성을 높일 수 있나요?

클라우드에서 관리대상 계정은 어플리케이션 계정과 개발자/관리자용 계정으로 구분된다고 볼 때 소개하시는 솔루션은 계정성격에 따라 관리정책이 다르게 적용되는지요? 그리고 계정 유형별 정책 사례가 궁금합니다

감사기록은 누적되어 의심스러운 행위를 한 사용자를 예측하고, 경고하는 알람 기능, 소명 기능 등도 있는지? 추가 할 수 있는지 궁금합니다.

OPA가 세션의 유지와 관계 없다면, 만약 3자가 이 토큰을 10분안에 탈취하면 이렇게 생성된 세션은 문제 없이 유지 될 수도 있지 않나요

외부사용자 뿐만 아니라 내부직원, 그리고 클라우드 인프라에 대한 접근 권한을 안전하게 관리할 필요가 있다는 것은 인지하고 있습니다. 기업 아이덴티티를 효율적으로 관리하기 위해 IAM 솔루션 도입이 필수적인 것인지요?

기존 옥타의 솔루션 대비 Okta Privileged Access가 개선되고 특화된 점은 무엇이고, 두 솔루션 간의 도입 조건이나 비용 등의 차이가 있는지 문의 드립니다

제로트러스트구현에서 롤 아웃 및 전략적 관점에서 구글과 유사한면이 있는데 네트워크 계층에 중점을 두는면이 차별성이라고 생각되는데 기능상의 장점은 어떤게 있을까요?

[질문] 크리덴셜 스터핑, 인포스틸러 등의 계정 탈취 공격을 통한 내부 시스템 침투에 대한 접근제어 및 보호 측면에서 어떤 강점을 가지고 있는지 궁금하며, 보안사고가 나더라도 확실한 원인 분석으로 사후 대처를 명확히 할 수 있는 기능이 마련되어 컴플라이언스 대응과 시스템 운영의 보안 관리체계를 강화할 수 있는지 문의드립니다.

ZTA기반이라 함은 최소권한원칙에 의해 초기엔 권한이 거의 없을텐데, 이 경우 승인권자가 승인해야 하는 권한부여가 너무 빈번하고, 많이 발생하지는 않나요

서버 인스턴스가 많아질 경우에도 접근 제어의 성능에 영향이 없는지 궁금합니다.

다수의 서버에 대한 접근 권한 설정을 간소화하는 과정에서 발생할 수 있는 보안 취약점은 없나요?

passwordless 인증을 통해 피싱이나 스터핑등 비밀번호 위조공격을 예방하는 알고리즘이 궁금합니다.

관리자 입장에서 데모에서 보여지는 것 처럼 옥타 솔루션의 기능을 제대로 활용하려면 교육 또는 충분한 사용을 통해 익숙해야 가능할 것 같다는 생각이 듭니다. 정보화 또는 보안 담당자라고 해서 해당 건만 관리하는 것이 아니기에 수 많은 보안 솔루션의 관리가 쉽지 않는데, 데모에서 보여주신 내용을 여러단계 거치지 않고 한두단계만으로 기능을 적용하거나 할 수 있는 방안은 없을까요? 템플릿화 하거나 등등

기존 서버 접근 제어 보안과 비교하여 권한 설정이 더 상세하게 설정을 자동화를 통해 관리가 어디까지 지원되는지요? 인증에 대한 접근 시간 등 제한은 무엇이 있는지요?

공공기관 업무망과 같이 인터넷과 소통이 안되는 상태에서도 서버 접근제어 기능을 구현함에 부족함이 없는지 궁금합니다. 공공기관 구축 레퍼런스도 있는지요?

예를들어 사용자가 작업 후 save 하려할 때, 그 권한이 없음을 발견했다면, 그때까지 작업한 워킹 컨텍스트 는 모두 잃는 건가요, 혹은 현재 활성화된 세션에 추가로 권한을 부여할 수도 있나요?

악성로그인 시도를 식별 및 차단하는데 있어 AI머신러닝을 통한 과거의 공격시도 데이터를 참조하여 차단하는 방식은 있는지 오탐을 최소화하는방안은 어떻게 되는지 궁금합니다.

기존의 서버 접근 통제 시스템을 사용 중인 기업이 Okta Privileged Access로 전환할 때, 어떤 마이그레이션 절차가 필요한가요?

Okta Privileged Access가 제공하는 사용자 접근 이력 추적 및 모니터링 기능은 어떻게 동작하나요?

그러한 추가 권한 부여가 되지 않는다면 초기에 꽤 많은 사용자 불만이 발생할 수도 있겠군요...

온프레미스와 클라우드 간 하이브리드 환경에서도 Okta Privileged Access를 효율적으로 사용할 수 있나요?

의심되는 악성사이트에 대한 IP/URL정보의 소스 및 신뢰도와 업데이트 주기는 어떻게 되는지 궁금합니다.

Tcp 22나 7234는 OPA가 전혀 제어할 수 없는 connection 이 되나요? 그럼 opa의 효과가 반감될 수도 있지 않나요

SAAS서비스의 경우 투자비용 및 관리인원 절감효과등이 있는 반면 장애 및 보안침해시 리스크가 커지는데 이에 대한 대책이 있는지 궁금합니다.

서버 접근 제어 정책을 규모에 맞게 커스터마이즈할 수 있는 유연성은 어떻게 제공되나요?

Okta PA는 다른 ID 및 접근 관리 시스템 또는 클라우드 서비스나 보안 솔루션과의 통합을 어떻게 이루어지며 권한 조정을 관리하기 위해선 어떤 방법이 사용되나요

혹시 사용자 PC에도 Agent 설치가 필요한가요?

혹시 BP 사례에 대한 안내 자료가 있을까요?

클라우드 기반으로 구성 시 사용자가 Legacy 시스템에 직접 로그인 시도 시 SSO portal 및 Legacy 시스템에 대한 인증 및 권한 관리 프로세스가 준비되어야 될 것 같은데, 이를 위해서는 통합 인증 체계를 운영해야 하는데 복수의 IAM을 활용하여 사용자 인증 프로세스를 표준화하는 방법은 없을까요?

보안 업데이트등 시스템작업에도 서비스 영향없이 가능한가요? 아니면 시스템 일시 중단이 필요한지요?

도입시 애플리케이션별 프로비저닝 요청 및 소요시간 단축등 수치화된 개선 데이터가 있는지요?

승인은 매번 일어나나요? 이로 인한 오버헤드나 사용자 불편은 없습니까?

기존 서버의 인증 방법에 문제인지 사용자 누군가가 대용량 작업을 하게 되면 전체 속도 저하 및 사내 전산 다운까지 일어나는 경우가 종종 있는데 인증방법을 효율적으로 관리 또는 각 사용자별로 각 작업용도에 따라 개별 인증방법을 제어할수 있을까요?

국내에서는 외부 사용자를 위한 SSO, MFA가 많이 구현되어있는데 내부 사용자에 대한 SSO, MFA 구현이 많이 이루어는것이 바람직스러운것인지요?

접근 허용시간이 설명해 주신대로 10-15분 정도라면 말이죠....

현재 업계 동향 및 앞으로의 발전 방향에 대해서 문의드립니다.

옥타의 서버접근제어와 기존에 사용하고 있는 서버접근제어와 충돌되는 부분은 없을까요? 충돌되는 부분이 없다면 둘다 서버접근 제어 정책이 적용되었을 때 우선순위는 어디가 먼저일까요?

클라우드와 온프레미스 환경 모두에서 동일한 MFA 설정을 적용할 수 있나요?

Opa가 SaaS라면 이는 connection 단위로 서비스 되나요? 아니면 token 발행 갯수나 request 숫자에 따르나요? 과금 역시 이렇게 될 것 같은데, 종래의 사용자별도 가능할 것 같네요

서버 접근 권한에 대한 위험 분석을 Okta Privileged Access가 자동으로 수행할 수 있나요? 이를 통해 접근 권한이 남용되거나 악의적인 활동이 감지될 경우 실시간으로 경고를 보내는 기능이 있는지 궁금합니다.

OPA의 기능성과 효율성 그리고 편의성 측면이 매우 눈의 띄는 것 같습니다. 담당자가 정책이나 권한을 세분화 시킨 후 만약 그 담당자가 갑자기 일이 생겨서 대체자 혹은 후임자가 해당 롤을 대신할 경우 기존 업무들을 이해하기 위한, 권한을 카테고리화 하거나 파악하기 쉽게 영향도의 시각화 해준다거나 하는 기능이 있을까요?

내부 위협에 대한 대응책으로 Okta Privileged Access는 어떤 기능을 제공하나요? 예를 들어 내부 사용자에 의한 잘못된 접근 시도가 발생할 때 어떻게 관리되나요?

솔루션 한글화가 되어 있나요?

최근 LLM이 유행인데, 내용에 따라 인공지능을 이용하여 내용에 의한 자동 접근 제어가 가능한지 궁금하네요..

서버 접근 제어 정책을 부서 역할 프로젝트에 따라 유연하게 설정할 수 있는지 궁금합니다? 특정 프로젝트 팀이 일정 기간 동안만 특정 서버에 접근할 수 있도록 설정할 수 있나요?

저렇게 password 를 바꿔도 애초 connection 을 만들지 못하면 무용한 것 아닌가요? 즉 퇴사시 shared account 를 잠그면 그만 아닌가요

Role에 대한 group 을 생성하는 방식이 가능하다면, 기존에 사용하던 RBAC를 바로 변환하여 사용하는 것도 가능할까요

접근제어 솔루션과 같이 사용하면 시너지 효과가 있는 솔루션이 있을거 같은데요. 어떤 것이 있을까요?

기존의 옥타 사용자라도 별도의 Okta Privileged Access 권한을 구매하여 사용해야 하는 것인지요?

아이덴티티 솔루션을 사용하게 되면 정책 기반으로 운영되고 있는 결제 시스템에 대한 간소화 기능도 있을까요?

1.제로 트러스트 기반 보안 체계 구축 시 고려사항과 사용자 권한등급 관리나 데이터 및 애플리케이션 보안 관리 방안이 궁금합니다. 2.최근 제로트러스트 이슈가 보안산업에 영향을 미치면서 보안 솔루션에 제로트러스트가 접목되고 있는걸로 알고 있습니다. 엔드포인트에 제로트러스트를 도입한 사례와 제로트러스트 전략으로 AI기반 LLM의 취약점을 이용한 공격에 대응할수 있는지도 궁금합니다.

Okta Privileged Access를 도입하려면 기존 Okta 솔루션이나 타 제품 대비 필수 혹은 추가로 준비하거나 고려해야 하는 사항이 있나요?

Server 가 아닌 secret, 개인정보 같은 경우 그 대상이 전체 db의 일부, 혹은 file server의 특정 disk 와 같은 것이 될텐데 현재 Opa는 이런 객체 일부도 가능한가요, 아직은 전체 서버 리소스에 대한 제어만 가능한가요

기존의 edr, xdr 이 있다면 gateway 의 기능을 off 할 수도 있나요? 설명해 주신 바에 의하면 gateway 의 기능은 logging 이라 하셔서 이중 기록의 필요는 없을 것 같은데요

[질문] Okta Privileged Access 의 다른 인프라나 소프트웨어와의 호환성은 어떠한가요?

기존 Okta 서비스에서 사용한 접근제어 권한이나 정책 파일을 백업 받아 Okta Privileged Access에 적용도 가능한지요?

이전 질문이 좀 애매했던 것 같은데, 현재 OPA는 db 의 특정 record, field(column)나 file server의 특정 disk 와 같은 단뤼로도 access control 이 가능한가요

Okta Privileged Access를 도입하기 위한 기본 조건은 어떤 것들이 있나요?

데모 형태로 직접 체험해 볼 수 있는 가상 공간도 마련이 되어 있나요?

타사의 경우 IAM을 계정관리와 인증을 SaaS와 PaaS로 나누어서 관리하는 케이스가있는데, Okta의 경우 SaaS에서 계정관리와 인증을 모두 통합 운영하는지 궁금합니다.

[질문]옥타 솔루션으로 가게 되면 기존 WINS로 접근제어를 사용하고 있는데, 기존 정책을 모두 포함하면서 더 추가의 option을 제공할 수 있나요?

현재 identification/ authentication tool 로 Okta 를 사용하고 있지 않더라도 OPA의 도입에 문제 없을까요

첫 부분에 k8s 같은 container 단위의 ac도 가능하다고 하신 것 같은데, 그 단위는 생성되어 작동하는 pod 가 되는 건가요

보안가시성과 운용상의 편이성 및 보안의 강화가 동시에 가능한 방안이 있는지요?

마지막 질문인데, 그렇다면 opa 의 최적 적용예는 lambda 와 같은 server less entity 의 provisioning 과 관련된 ac 같은데 이런 예가 있을까요

수고하셨습니다

많은 도움이 되었습니다.

수고하셨습니다.

수고많으셨습니다~

수고하셨습니다