260706_1_계정, 로그인, 보안 초안 작성
This commit is contained in:
@@ -0,0 +1,263 @@
|
||||
기업대상으로 saas프로그램을 개발중인데 로그인 /회원가입 기능을 구현하려고해. 여기서 법적이나 기능적으로 신경써야 하는게뭐야?
|
||||
|
||||
기업 대상(B2B) SaaS 프로그램은 일반 개인 대상(B2C) 서비스보다 보안, 권한 관리, 규제 준수(Compliance) 기준이 훨씬 엄격합니다. 로그인 및 회원가입 기능 구현 시 반드시 반영해야 할 법적·기능적 핵심 체크리스트를 정리해 드립니다.
|
||||
|
||||
1. 법적 고려사항 (Legal & Compliance)
|
||||
국내법(개인정보 보호법, 정보통신망법) 및 글로벌 표준을 기준으로 아래 사항을 반드시 준수해야 합니다.
|
||||
|
||||
필수 약관 및 동의 항목 분리
|
||||
|
||||
이용약관과 개인정보 처리방침은 반드시 사용자가 동의를 체크해야 가입이 되도록 설정해야 합니다.
|
||||
|
||||
마케팅 목적의 수신 동의(이메일/SMS)는 반드시 '선택' 항목으로 분리해야 하며, 기본 체크 해제 상태여야 합니다. (위반 시 과태료 대상)
|
||||
|
||||
개인정보 암호화 및 전송 보안
|
||||
|
||||
비밀번호 일방향 암호화: DB에 저장할 때 bcrypt, scrypt, PBKDF2 같은 강력한 해시 알고리즘을 사용해야 합니다. (평문 저장 절대 금지)
|
||||
|
||||
전송 구간 암호화: 로그인/회원가입이 일어나는 모든 페이지는 반드시 HTTPS(TLS)가 적용되어야 합니다.
|
||||
|
||||
개인정보 최소 수집 원칙
|
||||
|
||||
B2B 서비스 특성상 가입 시점에 주민등록번호 등 민감한 식별정보를 수집하면 안 됩니다. 이메일, 이름, 회사명, 부서 등 서비스 제공에 필요한 최소한의 정보만 수집하세요.
|
||||
|
||||
기업 대상 보안 인증 (장기적 관점)
|
||||
|
||||
향후 대기업이나 공공기관을 고객사로 유치할 경우, ISMS-P(국내)나 ISO 27001(글로벌) 인증을 요구받을 수 있습니다. 초기 설계 때부터 로그인 이력 저장 등 보안 표준을 염두에 두는 것이 좋습니다.
|
||||
|
||||
2. 기능적 고려사항 (Functional Requirements)
|
||||
B2B SaaS의 로그인/회원가입은 '개인'이 아닌 '기업(조직) 단위'의 워크스페이스 구조를 기반으로 설계해야 합니다.
|
||||
|
||||
① B2B 특화 회원가입/인증 흐름
|
||||
워크스페이스(Tenant) 생성 및 초대 구조:
|
||||
|
||||
A 회사의 관리자가 먼저 가입하여 '회사 워크스페이스'를 생성하고, 이후 팀원들은 관리자의 이메일 초대 링크를 통해 가입하는 흐름이 기본적입니다.
|
||||
|
||||
도메인 기반 자동 가입 (Domain Auto-Join):
|
||||
|
||||
@company.com 같은 특정 기업 도메인으로 가입 시, 해당 기업의 워크스페이스로 자동 소속되게 하는 기능입니다. (엔터프라이즈 고객 선호)
|
||||
|
||||
② 엔터프라이즈급 보안 기능
|
||||
기업용 SSO (Single Sign-On) 연동:
|
||||
|
||||
대기업 고객은 자신들이 쓰는 사내 계정(Google Workspace, Microsoft Entra ID/Azure AD, Okta 등)으로 로그인하길 원합니다. SAML 2.0이나 OIDC(OpenID Connect) 기반의 SSO 연동 확장이 가능하도록 인증 구조를 설계해야 합니다.
|
||||
|
||||
다요소 인증 (MFA / 2FA):
|
||||
|
||||
관리자 권한을 가진 계정이나 보안이 중요한 기업을 위해 이메일, SMS, 또는 OTP 앱(Google Authenticator)을 통한 2차 인증 기능을 선택 또는 필수 옵션으로 제공해야 합니다.
|
||||
|
||||
동시 로그인 제한 및 세션 만료:
|
||||
|
||||
보안을 위해 일정 시간 동안 활동이 없으면 자동으로 로그아웃되는 Session Timeout 기능과, 하나의 계정으로 여러 기기에서 동시 로그인하는 것을 제어하는 기능이 필요합니다.
|
||||
|
||||
③ 계정 관리 및 감사 (Audit)
|
||||
RBAC (Role-Based Access Control):
|
||||
|
||||
가입 후 조직 내에서 권한을 분리해야 합니다. (예: 소유자/Owner, 관리자/Admin, 일반 멤버/Member, 청구 관리자/Billing)
|
||||
|
||||
감사 로그 (Audit Log):
|
||||
|
||||
기업의 보안 담당자는 사용자의 로그인 일시, IP 주소, 기기 정보 등의 로그를 요구합니다. 로그인 성공/실패 이력을 DB나 로그 시스템에 엄격히 기록해두어야 합니다.
|
||||
|
||||
무차별 대입 공격(Brute Force) 방지:
|
||||
|
||||
로그인 실패가 5회 이상 반복될 경우 계정을 잠그거나, 캡차(reCAPTCHA)를 노출하고 일정 시간 로그인을 차단하는 방어 로직이 필수적입니다.
|
||||
|
||||
현재 타겟으로 삼고 계신 고객사의 규모(스타트업/중소기업 vs 대기업·공공기관)나, 다루시는 서비스의 도메인(금융, 의료, 일반 협업툴 등)은 구체적으로 어떻게 되시나요?
|
||||
|
||||
법적요소는 제외하고 주 고객은 30인 미만의 기업들이 대상이야. 그래서 조직베이스로가되 먼저 가입자를 대상으로 회사정보를 받고 다음부터는 가져와 사용하는거지. 이때 가입아이디는 회사계정을 사용하여 아이디에활용하고 재직여부를 체크하는거야. 도메인, sso 불필요 다인증 방식은 이메일로, rbac는 불필ㅇ요
|
||||
|
||||
30인 미만의 소규모 기업을 타깃으로 하며 SSO, RBAC, 복잡한 도메인 관리 없이 ‘이메일 인증’과 ‘회사 단위(Organization)의 간결함’에 집중한 구조군요.
|
||||
|
||||
이 조건에 맞춰 대기업용 스펙을 걷어내고, 가장 빠르고 효율적으로 구현할 수 있는 기능적 핵심 설계 포인트를 정리해 드립니다.
|
||||
|
||||
1. 회원가입 및 조직 연동 흐름 (기능 설계)
|
||||
"첫 가입자가 회사 정보를 입력하고, 다음 사람부터는 이를 재사용한다"는 요구사항을 구현할 때, 복잡한 도메인 파싱 로직 없이 처리하는 가장 확실한 방법은 [초대 번호/회사 코드] 또는 [도메인 텍스트 매칭]입니다.
|
||||
|
||||
최초 가입자 (마스터 유저):
|
||||
|
||||
이메일(예: gildong@hong.com)로 가입 신청.
|
||||
|
||||
이메일로 발송된 6자리 인증코드 입력 (이메일 MFA 겸용).
|
||||
|
||||
인증 성공 후, 회사 정보 입력 폼 작성 (회사명, 사업자번호 등).
|
||||
|
||||
완료 시 DB에 Company 레코드가 생성되고, 해당 회사의 고유 '회사 코드(예: HONG-1234)'가 발급됨.
|
||||
|
||||
이후 가입자 (팀원):
|
||||
|
||||
이메일(예: chulsoo@hong.com)로 가입 신청 및 이메일 인증.
|
||||
|
||||
"기존 회사에 참여하기" 단계에서 먼저 가입한 동료에게 받은 '회사 코드'를 입력.
|
||||
|
||||
코드가 일치하면 해당 회사 정보(회사명 등)를 화면에 보여주며 확인을 받고, Company ID를 유저 계정에 바인딩.
|
||||
|
||||
💡 도메인 로직을 최소한으로 쓴다면?
|
||||
별도의 엔터프라이즈 도메인 기능은 없더라도, 이후 가입자가 코드를 입력했을 때 "최초 가입자의 이메일 도메인(@hong.com)과 현재 가입자의 도메인이 일치하는지" 백엔드에서 체크하는 방어 로직 하나만 넣어두면 잘못된 코드로 남의 회사에 들어가는 것을 쉽게 막을 수 있습니다.
|
||||
|
||||
2. '재직 여부 체크' 및 '이메일 다인증(MFA)' 구현 전략
|
||||
30인 미만 기업에서 인사 시스템(HRIS)이나 Active Directory 연동 없이 재직 여부를 확인할 수 있는 가장 완벽하고 비용이 적게 드는 방법은 "회사 이메일 계정의 소유권 지속 확인"입니다. 퇴사자는 회사 이메일이 가장 먼저 차단되기 때문입니다.
|
||||
|
||||
이메일 OTP 기반의 로그인 (MFA 겸용):
|
||||
|
||||
아이디/비밀번호 로그인 외에, 로그인할 때마다 또는 주기적(예: 30일마다)으로 등록된 회사 이메일로 6자리 인증코드를 보내 확인하게 합니다.
|
||||
|
||||
효과: 사용자가 퇴사하여 회사 이메일 계정이 정지되거나 삭제되면, 이 인증코드를 받을 수 없으므로 자연스럽게 서비스 접근이 차단(재직 체크 완료)됩니다.
|
||||
|
||||
세션 만료 기간 단축:
|
||||
|
||||
B2B 서비스이므로 "로그인 유지하기"를 선택하더라도 최대 세션 유지 기간을 2주~1달 수준으로 제한하는 것이 좋습니다. 세션이 만료되어 재로그인할 때 이메일 인증을 다시 거치게 하면 재직 여부가 자동으로 걸러집니다.
|
||||
|
||||
3. RBAC가 없는 단순화된 데이터베이스(DB) 구조
|
||||
RBAC(역할 기반 권한 제어)가 필요 없으므로 DB 구조를 극도로 단순화할 수 있습니다. 1:N(회사:유저) 관계만 정의하면 됩니다.
|
||||
|
||||
[Company 테이블] [User 테이블]
|
||||
----------------- ---------------
|
||||
- id (PK) - id (PK)
|
||||
- company_name - email (ID로 사용)
|
||||
- company_code (고유 코드) - password_hash
|
||||
- created_at - company_id (FK -> Company.id)
|
||||
- is_master (최초 가입자 여부, 정산/수정용)
|
||||
- created_at
|
||||
권한 제어의 단순화:
|
||||
|
||||
모든 유저는 기본적으로 동일한 기능 권한을 가집니다.
|
||||
|
||||
다만, 회사 정보 수정이나 결제(구독) 관리 기능을 위해 is_master (또는 is_admin) 라는 Boolean 플래그 하나만 유저 테이블에 둡니다. 최초 가입자만 이 값을 true로 가집니다.
|
||||
|
||||
4. 실무 개발 시 놓치기 쉬운 디테일 (체크리스트)
|
||||
동일 도메인 프리랜서/아웃소싱 계정 예외 처리:
|
||||
|
||||
간혹 @gmail.com이나 @naver.com 같은 공용 이메일로 가입하려는 사용자가 있습니다. 소기업일수록 공용 메일을 회사 계정처럼 쓰는 경우가 많으므로, 공용 도메인으로 가입 시에는 "회사 코드가 일치해도 도메인 일치성 체크를 건너뛰는" 예외 예외 로직을 고려해야 합니다.
|
||||
|
||||
이메일 발송 인프라(SMTP) 신뢰도:
|
||||
|
||||
로그인 및 재직 확인이 '이메일 인증코드'에 의존하기 때문에, 인증 메일이 스팸함으로 가거나 발송이 지연되면 서비스 전체 사용성이 마비됩니다.
|
||||
|
||||
AWS SES, Stibee, Solapi 등 인증 메일 발송 성공률이 높고 속도가 빠른 전문 SaaS 인프라를 초기부터 연동해 사용하는 것을 강력히 권장합니다.
|
||||
|
||||
동시 로그인 차단 (선택사항):
|
||||
|
||||
30인 미만 기업 환경에서는 계정 하나를 생성해 온 직원이 돌려쓰는 편법을 쓰기 쉽습니다. 이를 방지하려면 새로운 기기에서 로그인 시 기존 기기의 세션을 끊어버리는(만료시키는) 로직을 넣어두는 것이 비즈니스 모델(ID당 과금 등) 유지에 유리합니다.
|
||||
|
||||
소규모 업장이라 도메인이 아닐수도 있어
|
||||
|
||||
아, 아주 중요한 지적입니다! 맞습니다. 30인 미만 소규모 업장이나 초기 스타트업, 자영업 형태의 기업들은 전용 도메인(@company.com) 없이 @gmail.com, @naver.com 같은 공용 이메일을 회사 업무용으로 그대로 쓰는 경우가 허다합니다.
|
||||
|
||||
공용 이메일을 쓴다면 기존에 도메인 기반으로 필터링하려던 로직을 완전히 뒤바꿔야 보안 사고(예: 남의 회사 데이터에 접근하는 일)를 막을 수 있습니다. 이 환경에 맞춘 현실적인 로그인/회원가입 기능 수정안을 제안해 드립니다.
|
||||
|
||||
1. 회사 연결 방식: '초대 코드' + '마스터 승인제'
|
||||
도메인이 일치하는지 확인할 수 없기 때문에, 두 번째 가입자부터는 100% 철저하게 사람이 확인하는 구조로 가야 합니다.
|
||||
|
||||
1단계: 초대 코드(또는 링크) 입력
|
||||
|
||||
먼저 가입한 마스터가 발급받은 '회사 고유 코드'를 입력하고 가입을 진행합니다.
|
||||
|
||||
2단계: '승인 대기' 상태 진입 (핵심)
|
||||
|
||||
코드가 맞다고 해서 바로 회사 워크스페이스에 접속시키면 안 됩니다. (코드가 유출되거나 무작위 대입으로 뚫릴 위험 존재)
|
||||
|
||||
팀원이 가입 버튼을 누르면 화면에 "관리자의 가입 승인을 기다리고 있습니다"라는 안내를 띄우고 진입을 차단합니다.
|
||||
|
||||
3단계: 마스터가 최종 승인
|
||||
|
||||
최초 가입자(마스터)에게 "홍길동(gildong@gmail.com)님이 가입을 요청했습니다"라는 알림을 주고, 마스터가 화면에서 [승인]을 눌러야만 최종적으로 해당 회사 멤버로 묶이게 합니다.
|
||||
|
||||
2. 재직 여부 체크 방식의 변화: '멤버 내보내기' 기능 필수
|
||||
전용 도메인을 쓸 때는 퇴사자의 메일 계정 자체가 회사에서 삭제되므로 이메일 OTP로 재직 확인이 자동화되었지만, 개인용 @gmail.com을 업무용으로 쓰던 직원이 퇴사하면 퇴사 후에도 그 메일 주소는 살아있습니다.
|
||||
|
||||
따라서 이메일 인증만으로는 퇴사자 차단이 불가능하므로, 시스템적으로 아래 두 가지 장치가 꼭 필요합니다.
|
||||
|
||||
마스터 전용 '멤버 관리(강제 퇴장)' 기능
|
||||
|
||||
RBAC(복잡한 권한)는 필요 없지만, 마스터 유저 화면에 [우리 회사 멤버 목록]을 볼 수 있는 심플한 페이지가 하나 있어야 합니다.
|
||||
|
||||
직원이 퇴사하면 사장님(마스터)이 목록에서 [내보내기] 또는 [비활성화] 버튼을 누르는 방식입니다. 이 버튼을 누르면 해당 유저의 company_id를 끊어버리거나 계정 상태를 inactive로 변경하여 즉시 로그아웃 및 접근 차단을 시킵니다.
|
||||
|
||||
로그인 세션 만료 알림
|
||||
|
||||
퇴사자가 한 달 전에 로그인해 둔 세션으로 계속 접속하는 것을 막기 위해, 로그인 유지 기간이 지나 세션이 만료될 때 "보안을 위해 다시 로그인해 주세요"라는 안내와 함께 튕겨내야 합니다. (이때 이미 내보내기 처리된 유저라면 로그인이 막힙니다.)
|
||||
|
||||
3. 회원가입 화면(UI/UX)에서의 팁
|
||||
공용 이메일을 쓰는 소규모 업장 타깃이라면, 가입 단계에서 유저가 헷갈리지 않게 명확한 가이드를 주는 것이 가입 이탈률을 줄이는 데 좋습니다.
|
||||
|
||||
"회사에서 업무용으로 사용하는 이메일을 입력해 주세요." 라는 문구를 인풋창 위에 배치합니다.
|
||||
|
||||
가입 화면 처음에 두 가지 버튼을 명확히 찢어놓는 것이 좋습니다.
|
||||
|
||||
[우리 회사 최초 가입자 (방 만들기)] → 회사 정보 입력 폼으로 이동
|
||||
|
||||
[동료에게 초대를 받으셨나요? (참여하기)] → 초대 코드 입력 창으로 이동
|
||||
|
||||
이렇게 설계하면 공용 도메인을 쓰더라도 보안을 챙기면서, 30인 미만 업장 사장님과 직원들이 아주 직관적으로 서비스를 시작할 수 있습니다.
|
||||
|
||||
회사마나 공용계정을 1-5개를 운영한다면
|
||||
|
||||
소규모 업장(예: 자영업, 프랜차이즈 매장, 소형 대리점 등)에서는 비용 절감이나 인수인계의 편의를 위해 shop1@gmail.com, sales_team@naver.com 같은 공용 계정 하나를 여러 직원이 공유해서 쓰는 경우가 실제로 아주 많습니다.
|
||||
|
||||
이 조건이 추가되면, 앞서 이야기한 '1인 1계정' 기준의 설계(이메일 OTP를 통한 자동 재직 확인 등)를 그대로 쓸 수 없습니다. 공용 계정 환경에 맞춰 인증 및 보안 로직을 어떻게 수정해야 하는지 핵심 포인트를 정리해 드립니다.
|
||||
|
||||
1. 로그인 정책의 대전환: '동시 로그인 허용'
|
||||
이전 답변에서는 계정 공유를 막기 위해 동시 로그인을 차단하라고 말씀드렸지만, 공용 계정이 전제라면 동시 로그인을 무조건 허용해야 합니다.
|
||||
|
||||
문제 상황: 매장 PC에서 '공용 계정'으로 로그인해서 쓰고 있는데, 외근 나간 직원이 모바일로 같은 계정에 로그인하는 순간 매장 PC가 로그아웃되면 업무가 마비됩니다.
|
||||
|
||||
해결책: 동일 계정으로 여러 기기(PC, 태블릿, 모바일 등)에서 세션이 동시에 유지되도록 백엔드 설계를 개방해야 합니다.
|
||||
|
||||
2. 이메일 인증(MFA)의 딜레마 해결: '기기 신뢰(Trust Device)'
|
||||
공용 계정은 비밀번호를 공유하지만, 해당 이메일의 실제 수신 권한은 사장님이나 매니저 한 명만 가지고 있는 경우가 많습니다. 따라서 로그인할 때마다 이메일 인증코드를 요구하면 교대 근무자나 아르바이트생은 로그인을 못 하는 대참사가 일어납니다.
|
||||
|
||||
해결책 (브라우저/기기 기억하기):
|
||||
|
||||
최초 가입 및 새로운 기기에서 처음 로그인할 때만 이메일 인증(MFA)을 거치게 합니다.
|
||||
|
||||
인증 성공 시 "이 브라우저/기기를 30일간 기억하기" 옵션을 제공합니다.
|
||||
|
||||
쿠키나 로컬 스토리지를 활용해 해당 기기에서는 한 달 동안 이메일 2차 인증 없이 ID/비밀번호만으로 바로 로그인할 수 있게 장벽을 낮춰주어야 합니다.
|
||||
|
||||
3. 공용 계정 환경에서 '퇴사자 차단(재직 체크)' 방법
|
||||
공용 계정의 가장 큰 취약점은 퇴사한 직원이 집에서 매장 비밀번호로 접속해 데이터를 보거나 조작할 수 있다는 점입니다. 이메일이 개인 소유가 아니므로 이메일 차단만으로는 해결되지 않습니다. 이를 막기 위해 다음 2가지 기능이 필수적입니다.
|
||||
|
||||
방법 A: 사무실/매장 IP 제한 (가장 추천)
|
||||
|
||||
소규모 업장은 대개 정해진 공간(사무실, 매장)에서만 업무를 봅니다.
|
||||
|
||||
마스터 설정 페이지에 "우리 매장 IP(또는 와이파이 환경)에서만 로그인 허용" 옵션을 넣는 것입니다. 이렇게 하면 퇴사자가 비밀번호를 알아도 집에서는 로그인이 불가능합니다.
|
||||
|
||||
방법 B: 비밀번호 변경 시 '모든 기기 강제 로그아웃'
|
||||
|
||||
직원이 퇴사하면 사장님은 공용 계정의 비밀번호를 바꿀 것입니다.
|
||||
|
||||
이때 비밀번호만 바뀌고 기존 기기들의 세션이 살아있으면 퇴사자 PC에서 계속 접속이 유지됩니다.
|
||||
|
||||
따라서 마스터가 비밀번호를 변경할 때 "기존에 로그인된 모든 기기 로그아웃(세션 만료)" 처리가 백엔드에서 동시에 일어나도록 구현해야 합니다. 그래야 출근한 직원들이 새 비밀번호로 다시 로그인하면서 퇴사자만 자연스럽게 튕겨 나갑니다.
|
||||
|
||||
4. 데이터 관리를 위한 팁: '심플 프로필' (선택 사항)
|
||||
RBAC(권한 분리)는 필요 없더라도, "누가 이 주문을 처리했지?", "누가 이 데이터를 지웠지?" 같은 최소한의 추적은 필요할 수 있습니다. 넷플릭스나 당근마켓 비즈니스 계정 같은 방식을 차용하면 소규모 업장에서 매우 유용하게 씁니다.
|
||||
|
||||
공용 계정(shop1@gmail.com)으로 로그인하면 바로 서비스 화면이 나오는 것이 아니라, "현재 사용하는 직원을 선택해 주세요"라는 단순 닉네임 선택 창을 띄우는 것입니다. (예: 매니저, 오전알바, 오후알바)
|
||||
|
||||
비밀번호는 공유하지만, 액션 로그(Audit Log)에는 선택된 닉네임이 남기 때문에 30인 미만 기업 내에서 책임 소지를 명확히 할 수 있어 사장님들이 매우 선호하는 구조입니다.
|
||||
|
||||
개인별로 계정을 만드는게 맞겠다..
|
||||
|
||||
현명한 결정이십니다! 아무리 소규모 업장이라도 공용 계정을 허용하는 순간, 나중에 데이터가 꼬이거나 보안 사고가 터졌을 때 책임 소재를 가리기가 불가능해집니다. 개발자 입장에서도 개인별 계정으로 가는 것이 예외 로직을 줄이고 시스템을 안정적으로 가져가는 가장 좋은 길입니다.
|
||||
|
||||
개인별 계정(공용 이메일 허용)으로 방향을 굳히셨으니, 가장 담백하고 직관적인 가입/인증 흐름을 최종 정리해 드립니다.
|
||||
|
||||
🛠️ 개인별 계정 기반의 최종 인증 프로세스
|
||||
1. 회원가입 및 조직 연결 (초대 코드 + 마스터 승인)
|
||||
도메인(@company.com)이 없어도 안심하고 유저를 묶을 수 있는 가장 확실한 방법입니다.
|
||||
|
||||
마스터(첫 가입자): 가입 후 회사 정보를 입력하고, 우리 회사 고유의 '초대 코드(예: ABC-789)'를 발급받아 직원들에게 공유합니다.
|
||||
|
||||
팀원(이후 가입자): 각자 개인 이메일(@gmail.com 등)로 가입한 뒤, 초대 코드를 입력합니다.
|
||||
|
||||
승인 대기: 코드가 맞더라도 즉시 접속되지 않고 [승인 대기] 상태가 됩니다. 마스터가 관리자 화면에서 "어, 이 메일 주소 우리 직원 맞네" 하고 [승인]을 누르면 가입이 최종 완료됩니다.
|
||||
|
||||
2. 이메일 인증 (MFA) 및 재직 체크
|
||||
개인 계정이므로 이메일 인증의 효율이 극대화됩니다.
|
||||
|
||||
로그인할 때마다, 혹은 보안상 안전하게 2~3주에 한 번씩 등록된 개인 이메일로 6자리 OTP 인증코드를 발송해 입력하게 합니다.
|
||||
|
||||
직원이 퇴사하면 마스터(사장님)가 멤버 목록에서 [내보내기] 버튼을 누릅니다. 백엔드에서는 해당 유저의 세션을 즉시 만료시키고 회사 ID(company_id) 연동을 끊어버립니다. 이제 그 직원은 자기 이메일로 로그인해도 우리 회사 데이터에 접근할 수 없습니다.
|
||||
Reference in New Issue
Block a user