Jitsi Meet에서 인증 및 비밀번호 보호를 활성화하는 방법

Jitsi Meet에는 두 가지 별도의 보안 제어 기능이 있습니다. 서버 인증은 회의 생성 권한을 결정하고, 회의실 비밀번호는 비밀번호를 모르는 사용자의 회의실 참여를 차단합니다. 이 두 기능은 서로 다른 문제를 해결하기 위해 설계되었습니다. 자체 호스팅 서버에서 기존 Prosody "보안 도메인" 설정은 회의실 생성 시 사용자 이름과 비밀번호를 요구하면서도 게스트의 참여는 허용할 수 있었습니다. 하지만 Jitsi의 최신 핸드북에서는 이러한 방식을 신규 설치 시 더 이상 사용하지 않도록 권장하고 있으며, 토큰 기반 인증을 권장합니다. 기존 관리자는 아래 절차를 호환성 가이드로 활용할 수 있지만, 신규 배포 시에는 지원되는 토큰 또는 ID 공급자 설정을 기반으로 계획해야 합니다.

회의실 비밀번호는 회의 중 별도로 설정되는 기능이며 서버 인증과 함께 유용하게 사용됩니다. 회의실이 시작된 후 비밀번호를 설정하고 비공개 채널을 통해 공유한 다음, 참가자를 초대하기 전에 다른 브라우저에서 접속 과정을 테스트해 보세요.

어떤 종류의 보호가 필요하신가요?

목표	사용	이 제품의 기능은 무엇인가요?
방 생성 권한을 제어하세요	서버 인증	방을 만들 때 승인된 Jitsi 계정 또는 토큰이 필요합니다. 게스트 설정에 따라 다른 사람들도 게스트로 참여할 수 있습니다.
기존 방의 개인 정보를 유지하세요	방 비밀번호	비밀번호 설정 후 참여하는 사람들은 모두 비밀번호를 입력해야 합니다. 이미 회의실에 있는 참가자는 내보내지지 않습니다.
주인이 도착할 때까지 손님들을 기다려 주세요.	로비 또는 호스트 대기 기능	별도의 입장 절차를 추가합니다. 방 비밀번호만으로는 신원을 확인하거나 비밀번호를 받은 사람을 검증할 수 없습니다.

소규모 회의의 경우 고유한 회의실 이름과 비밀번호만으로도 충분할 수 있습니다. 계정 기반 회의실 생성이 필요한 조직의 경우 서버 인증도 구성해야 합니다. 새로운 자체 호스팅 구축의 경우 구현 방식을 선택하기 전에 Jitsi의 최신 인증 가이드 와 관련 토큰 인증 설정 내용을 검토하십시오.

Jitsi 채팅방 하나에 비밀번호를 설정하여 보호하려면 어떻게 해야 하나요?

회의를 시작하고 도구 모음에서 보안 또는 회의 옵션 메뉴를 열고 암호 작업을 선택한 다음 강력한 회의실 암호를 입력하세요. 메뉴 레이블과 아이콘은 클라이언트 버전에 따라 다를 수 있습니다. 회의가 이미 진행 중인 경우 암호를 설정하면 향후 참가자에게 영향을 미칩니다. 이미 입장한 참가자는 자동으로 퇴장되지 않습니다. 기밀 유지가 중요한 경우 암호를 회의 링크와 별도로 보내세요.

Jitsi FAQ에 따르면 회의가 종료되면 회의실 암호가 삭제되므로 반복 회의에서 암호가 유지된다고 가정해서는 안 됩니다. 새 회의를 시작할 때마다 암호를 다시 설정하고 실제 환경에서 제대로 작동하는지 확인하십시오. 암호를 받거나 전달받은 사람은 누구나 회의에 참여할 수 있으므로 암호는 사용자 지정 액세스 목록과는 다릅니다. 회의 보호에 대한 자세한 내용은 Jitsi 공식 FAQ를 참조하십시오 .

서버 인증은 무엇을 변경합니까?

기존의 "보안 도메인" 설계에서 Prosody는 로컬 계정을 사용하여 회의실 생성자를 인증합니다. Jitsi는 인증되지 않은 참가자가 게스트 도메인을 통해 접속할 수 있도록 허용합니다. 이는 직원만 회의실을 생성하고 참가자는 계정이 필요하지 않은 경우에 유용합니다. 또한 모든 참가자가 로그인할 필요가 없습니다. 모든 사용자가 인증해야 하는 경우 게스트 액세스를 비활성화하거나 현재 인증 설계에서 사용하는 ID 및 액세스 정책으로 대체해야 합니다.

Jitsi 설명서에는 이 구형 보안 도메인 방식이 새 설치에는 더 이상 사용되지 않는다고 명시되어 있습니다. 이러한 제한 사항을 이해하고 호환되는 기존 서버를 유지 관리하는 경우에만 계속 진행하십시오. 편집하기 전에 Jitsi 설치 방법을 확인하고 Jitsi Meet 호스트 이름을 기록해 두십시오. Prosody, Jicofo 및 웹 구성 파일을 백업하고 구문 오류로 인해 서비스가 중단될 경우를 대비하여 활성 관리자 세션 또는 콘솔을 유지하십시오.

데비안 또는 우분투 패키지 설치에서 기존 보안 도메인 설정을 활성화하는 방법은 무엇입니까?

1. Prosody 가상 호스트를 변경합니다.

Jitsi 호스트 이름에 해당하는 Prosody 파일을 엽니다 /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. 아래 샘플 호스트 이름을 실제 도메인으로 바꿉니다. 메인 가상 호스트에서 인증 모드를 해시된 내부 암호로 변경합니다. 그 뒤에 게스트 가상 호스트를 추가합니다.

VirtualHost "jitsi.example.com"
    authentication = "internal_hashed"

VirtualHost "guest.jitsi.example.com"
    authentication = "jitsi-anonymous"
    c2s_require_encryption = false

guest.jitsi.example.com기존의 다른 옵션과 모듈은 그대로 유지하십시오. 이 구성에서는 내부 Jitsi 도메인이므로 해당 도메인 에 대한 DNS 레코드나 공개 인증서를 생성하지 마십시오 .

2. 웹 클라이언트에게 게스트 도메인에 대해 알려줍니다.

기존 객체를 열고 그 안에 /etc/jitsi/meet/jitsi.example.com-config.js내용을 추가하세요 . 기존 항목과 다른 항목들은 그대로 두고, 쉼표를 꼼꼼히 확인하세요.anonymousdomainhostsdomain

hosts: {
    domain: 'jitsi.example.com',
    anonymousdomain: 'guest.jitsi.example.com'
},

3. 지코포에서 인증을 활성화합니다.

편집 /etc/jitsi/jicofo/jicofo.conf. 기존 jicofo블록 내에 인증 설정을 추가하세요. 최상위 블록을 중복해서 만들지 마세요.

jicofo {
  authentication {
    enabled = true
    type = XMPP
    login-url = "jitsi.example.com"
  }
}

파일에 이미 해당 jicofo섹션이 있는 경우, 이러한 속성을 해당 섹션에 병합하십시오. 구성 구문 및 생성된 파일은 패키지 버전에 따라 다를 수 있으므로 서비스를 다시 시작하기 전에 결과를 설치 버전의 설명서와 비교하십시오.

4. 서비스를 재시작하고 계정을 생성하세요.

수정 사항을 확인한 후 관리자 권한으로 서비스를 다시 시작하십시오.

sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jitsi-videobridge2

Prosody에 룸 생성자 계정을 등록하세요. 자리 표시자를 실제 값으로 바꾸세요. 실제 서버에서는 예시 도메인이나 취약한 비밀번호를 절대 사용하지 마세요.

sudo prosodyctl register <username> jitsi.example.com <strong-password>

각 계정은 Jitsi 호스트 이름과 연결됩니다. 나중에 액세스 권한을 취소해야 하는 경우 관리자 자격 증명을 공유하는 대신 개별 계정을 생성하세요. Jitsi의 보안 도메인 설명서 에는 패키지별 구성 경로와 등록 명령이 나와 있습니다. 또한 해당 방법이 더 이상 사용되지 않음을 명시적으로 언급하고 있습니다.

Docker 환경에서의 설정 방식은 어떻게 다른가요?

실행 중인 컨테이너 내부의 파일을 편집하거나 Debian 패키지 경로를 Docker 배포 환경에 복사하지 마십시오. 공식 Docker Compose 설정에서는 배포 환경 파일을 통해 인증이 구성됩니다. 핸드북에는 내부 계정 인증에 필요한 관련 값이 설명되어 있습니다.

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

참석자가 자신의 계정 없이도 참여할 수 있도록 하려면 게스트 액세스를 활성화 상태로 유지하세요. 게스트 액세스가 활성화된 경우, 인증되지 않은 사용자는 구성된 게스트 동작에 따라 참여할 수 있지만, 인증된 회의실 생성자가 되지는 않습니다. 배포를 위해 Compose 워크플로를 사용하여 환경 변경 사항을 적용하고, 서비스가 정상적으로 시작되지 않으면 로그를 확인하세요.

생성된 컨테이너 구성을 변경하는 대신 Prosody 서비스를 통해 내부 사용자를 생성하세요. 공식 설명서에는 Prosody 컨테이너에서 셸을 열고 다음 명령어를 사용하여 사용자를 등록하는 방법이 나와 있습니다 . 구성 경로와 prosodyctlXMPP 도메인은 Compose 릴리스에 따라 다릅니다. 문서화된 Docker 이미지에서 Prosody 구성은 `/ prosody / /config/prosody.cfg.luaconfig ...meet.jitsi

보안 기능이 제대로 작동하는지 어떻게 확인할 수 있나요?

개인 정보 보호 모드 브라우저 창을 열고 새 방을 만들어 보세요. 일반적인 설정 과정에서는 계정 자격 증명을 입력하라는 메시지가 나타날 것입니다.
새 계정으로 로그인하고 회의실을 만드세요. 회의가 제대로 로드되고 호스트에게 필요한 진행자 권한이 있는지 확인하세요.
다른 브라우저에서 게스트로 접속하세요. 게스트 접속이 허용된 경우, 생성자 계정 없이도 접속이 가능합니다. 추가적인 입장 확인이 필요한 경우, 회의실 비밀번호 또는 로비 비밀번호를 입력하세요.
방 비밀번호를 설정한 다음, 비밀번호를 설정하지 않은 상태와 설정한 상태로 새 개인 창에서 접속을 시도해 보세요. 비밀번호를 설정한 후에도 이미 접속 중인 참가자가 연결 상태를 유지하는지 확인하세요.
테스트 회의를 종료한 후 새 회의실을 만들고 Jitsi FAQ에 설명된 대로 비밀번호를 다시 설정해야 하는지 확인하십시오.

로그인 프롬프트가 전혀 나타나지 않으면 Prosody 호스트 이름, Jicofo 블록, 클라이언트 anonymousdomain값 및 서비스 로그를 확인하십시오. 일반적인 구성 오류는 Prosody와 호스트 이름 간에 일치하지 않는 게스트 도메인을 사용 config.js하거나 기존 Jicofo 블록을 확장하는 대신 두 번째 Jicofo 블록을 추가하는 경우입니다. 게스트가 참여할 수 없는 경우 게스트 액세스가 의도적으로 활성화되었는지, 구성된 게스트 도메인이 기본 호스트 이름과 일치하는지 확인하십시오.

새로운 설치를 위해 무엇을 선택해야 할까요?

특별한 호환성 문제가 없는 한, 더 이상 사용되지 않는 보안 도메인 레시피를 사용하여 새 배포를 시작하지 마십시오. Jitsi의 최신 자체 호스팅 자료에서는 새 설치에 토큰 인증을 권장하며, 더 광범위한 인증 가이드에서는 최신 ID 공급자 통합에 대해 설명합니다. 이러한 접근 방식에는 추가적인 발급자, 서명 또는 ID 공급자 구성이 필요하며, Prosody 회의실 암호와는 호환되지 않습니다. 요구 사항에 맞는 모델을 선택한 다음, 필요에 따라 회의실 암호 또는 로비를 별도의 회의 수준 제어 수단으로 사용하십시오.

요약하자면, 계정 또는 토큰 인증을 사용하여 누가 방을 만들 수 있는지 제어하고, 방 비밀번호를 설정하여 비밀번호를 아는 사람만 나중에 참여할 수 있도록 제한하세요. 두 가지 방법을 각각 독립적으로 테스트해야 합니다. 한 가지 방법을 활성화한다고 해서 다른 방법이 자동으로 활성화되는 것은 아니기 때문입니다.