Firebase 리소스와 사용자의 데이터를 안전하게 보관하려면 다음 가이드라인을 따르세요. 모든 항목이 필수적으로 요구사항에 적용되는 것은 아니지만, 앱을 개발할 때 유의해야 합니다.
악성 트래픽 방지
백엔드 서비스에 대한 모니터링 및 알림을 설정하세요
서비스 거부(DOS) 공격과 같은 악성 트래픽을 감지하려면 Cloud Firestore, Realtime Database, Cloud Storage, Hosting에 대한 모니터링과 알림을 설정합니다.
애플리케이션에서 공격이 의심되는 경우 가능한 한 빨리 지원팀에 문의하여 상황을 알려주세요.
App Check를 사용 설정하세요
내 앱만 백엔드 서비스에 액세스할 수 있도록 하려면 앱 체크를 지원하는 모든 서비스에서 Firebase App Check를 사용 설정하세요.
일반 트래픽에 맞게 확장되도록 Cloud Functions를 구성하세요
Cloud Functions는 앱의 요구에 맞게 자동으로 확장되지만 공격이 발생할 경우 손실이 커질 수 있습니다. 이를 방지하려면 앱의 일반 트래픽에 따라 함수의 동시 실행 인스턴스 수를 제한하면 됩니다.
한도에 거의 도달하면 알림을 받도록 설정하세요
서비스에 요청이 급증할 경우 종종 할당량이 시작되고 애플리케이션에 대한 트래픽이 자동으로 제한됩니다. 사용량 및 결제 대시보드를 모니터링해야 하지만, 프로젝트에 예산 알림을 설정하여 리소스 사용량이 예상을 초과할 때 알림을 받을 수도 있습니다.
자체 DOS 방지: 에뮬레이터로 로컬에서 함수를 테스트하세요
예를 들어 무한 트리거 쓰기 루프를 생성하여 Cloud Functions를 개발하는 동안 실수로 DOS를 실행하기 쉽습니다. Firebase Local Emulator Suite으로 개발을 수행하여 이러한 오류가 실시간 서비스에 영향을 미치지 않도록 할 수 있습니다.
실수로 DOS를 실행한 경우, index.js에서 함수를 삭제하여 배포 해제한 다음 firebase deploy --only functions
실시간 응답성이 매우 중요한 것이 아니라면 함수를 방어적으로 구조화하세요
함수의 결과를 실시간으로 제공할 필요가 없는 경우 일괄로 결과를 처리하여 악성 트래픽을 최소화할 수 있습니다. Pub/Sub 주제로 결과를 게시하고 예약된 함수를 사용해 정기적인 간격으로 결과를 처리합니다.
API 키 이해
Firebase 서비스의 API 키는 보안 비밀이 아닙니다
Firebase는 API 키만 사용하여 Firebase 서비스에 대한 앱의 Firebase 프로젝트를 식별하며, Firebase Security Rules을 사용하여 수행되는 데이터베이스 또는 Cloud Storage 데이터에 대한 액세스는 제어하지 않습니다. 이러한 이유로 Firebase 서비스의 API 키를 보안 비밀로 취급할 필요가 없으며, 클라이언트 코드에 안전하게 삽입할 수 있습니다. Firebase용 API 키 자세히 알아보기
API 키 제한사항을 설정하세요
API 키를 사용하여 요청을 스푸핑하려는 공격자에 대한 추가 방어 수단으로 API 키 제한사항을 추가하여 API 키의 범위를 앱 클라이언트 및 사용하는 API로 지정할 수 있습니다.
FCM 서버 키를 보안 비밀로 유지하세요
Firebase 서비스의 API 키와 달리 FCM 서버 키(기존 FCM HTTP API에서 사용)는 민감하며 보안 비밀로 유지해야 합니다.
서비스 계정 키를 보안 비밀로 유지하세요
Firebase 서비스의 API 키와 달리 Firebase Admin SDK에서 사용하는 서비스 계정 비공개 키는 민감하며 보안 비밀로 유지해야 합니다.
Firebase Security Rules
프로덕션 또는 잠금 모드에서 규칙을 초기화하세요
Cloud Firestore, Realtime Database, Cloud Storage를 설정할 때 기본적으로 보안 규칙을 초기화하여 모든 액세스를 거부하고 앱을 개발함에 따라 특정 리소스에 대한 액세스 권한을 부여하는 규칙을 추가합니다.
Cloud Firestore(프로덕션 모드) 및 Realtime Database(잠금 모드)에서 새 인스턴스에 대한 기본 설정 중 하나를 사용합니다. Cloud Storage의 경우 다음과 같은 보안 규칙 구성부터 시작합니다.
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
보안 규칙은 스키마이며 문서 추가 시 규칙을 추가하세요
사전 출시 작업으로 앱을 작성한 후에는 보안 규칙을 작성하지 마세요. 대신 앱을 작성할 때 보안 규칙을 작성하여 데이터베이스 스키마처럼 취급합니다. 새 문서 유형 또는 경로 구조를 사용해야 할 때는 언제나 보안 규칙을 먼저 작성하세요.
Local Emulator Suite으로 보안 규칙을 단위 테스트하고 CI에 추가하세요
앱 개발에서 보안 규칙이 정상적으로 실행되도록 하려면 Firebase Local Emulator Suite으로 규칙을 단위 테스트하고 이러한 테스트를 CI 파이프라인에 추가합니다. Cloud Firestore 및 Realtime Database에 관한 가이드를 참고하세요.
인증
커스텀 인증: 신뢰할 수 있는(서버 측) 환경에서 JWT를 생성하세요
커스텀 시스템이든 타사 서비스이든 보안 로그인 시스템을 이미 갖추고 있다면 기존 시스템을 사용하여 Firebase 서비스를 인증할 수 있습니다. 신뢰할 수 있는 환경에서 커스텀 JWT를 생성한 다음 인증을 위해 토큰을 사용하는 클라이언트(iOS+, Android, 웹, Unity, C++)에 토큰을 전달합니다.
서드 파티 제공업체에 커스텀 인증을 사용하는 예시는 Okta를 사용하여 Firebase 인증 블로그 게시물을 참조하세요.
관리형 인증: OAuth 2.0 공급자가 가장 안전합니다
Firebase의 관리형 인증 기능을 사용하는 경우 OAuth 2.0/OpenID Connect 제공업체 옵션(Google, Facebook 등)이 가장 안전합니다. 가능한 경우 이러한 제공업체 중 하나 이상을 지원해야 합니다(사용자층에 따라).
이메일 비밀번호 인증: 무차별 공격을 방지하기 위해 로그인 엔드포인트에 대한 엄격한 할당량을 설정하세요
Firebase의 관리형 이메일 비밀번호 인증 서비스를 사용하는 경우 무차별 공격을 방지하기 위해 identitytoolkit.googleapis.com 엔드포인트의 기본 할당량을 엄격하게 설정합니다. Google Cloud 콘솔의 Identity Toolkit API 페이지에서 이 작업을 수행할 수 있습니다.
이메일-비밀번호 인증: 이메일 열거 보호 사용 설정
Firebase의 관리형 이메일 비밀번호 인증 서비스를 사용하는 경우 악의적인 행위자가 프로젝트의 인증 엔드포인트를 악용하여 계정 이름을 추측하지 못하게 하기 위해 이메일 열거 보호 기능을 사용 설정합니다.
다중 인증(MFA)용 Google Cloud Identity Platform으로 업그레이드하세요
로그인에 추가 보안을 설정하려면 Google Cloud Identity Platform으로 업그레이드하여 다중 인증 지원을 추가할 수 있습니다. 업그레이드 후에도 기존 Firebase Authentication 코드는 계속 작동합니다.
익명 인증
사전 온보딩에는 익명 인증만 사용하세요
익명 인증만 사용하면 사용자가 실제로 로그인하기 전에만 기본 상태를 저장할 수 있습니다. 익명 인증은 사용자 로그인을 대체하지 않습니다.
다른 기기에서 데이터를 원할 경우 사용자의 로그인 방법을 전환하세요
사용자가 로컬 스토리지를 지우거나 기기를 전환해도 익명 인증 데이터는 유지되지 않습니다. 단일 기기에서 앱을 다시 시작한 후에도 데이터를 계속 유지해야 한다면 사용자를 영구 계정으로 전환하세요.
사용자가 로그인 제공업체로 전환해야 하거나 이메일을 확인해야 하는 보안 규칙을 사용하세요
누구나 프로젝트에서 익명 계정을 만들 수 있습니다. 이 점을 고려하여 특정 로그인 방법 또는 확인된 이메일 주소가 필요한 보안 규칙으로 모든 비공개 데이터를 보호하세요.
예를 들면 다음과 같습니다.
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Cloud Functions 안전성
환경 변수에 민감한 정보를 입력하지 마세요
종종 자체 호스팅 Node.js 앱에서 환경 변수를 사용하면 비공개 키와 같은 민감한 정보를 포함할 수 있습니다. Cloud Functions에서는 민감한 정보를 포함하지 마세요. Cloud Functions는 함수 호출 간에 환경을 재사용하므로 민감한 정보를 환경에 저장해서는 안 됩니다.
보안 비밀이 아닌 Firebase API 키를 저장하려면 코드에 삽입하기만 하면 됩니다.
Cloud Functions에서 Firebase Admin SDK를 사용하는 경우 Admin SDK가 초기화 중에 자동으로 가져올 수 있으므로 서비스 계정 사용자 인증 정보를 명시적으로 제공하지 않아도 됩니다.
서비스 계정 사용자 인증 정보가 필요한 Google 및 Google Cloud API를 호출하는 경우, Node.js용 Google 인증 라이브러리는 자동으로 채워지는 Cloud Functions의 애플리케이션 기본 사용자 인증 정보에서 이러한 사용자 인증 정보를 가져올 수 있습니다.
Cloud Functions에 Google 이외의 서비스에 대해 비공개 키와 사용자 인증 정보를 사용할 수 있게 하려면 Secret Manager를 사용하세요.
민감한 정보는 암호화하세요
함수에 민감한 정보를 전달하는 것이 불가피한 경우 자체 커스텀 솔루션을 제공하여 정보를 암호화해야 합니다.
단순한 함수가 더 안전하지만 복잡한 구성이 필요하다면 Cloud Run을 사용하세요
함수를 최대한 기본적이고 이해하기 쉽게 유지하세요. 함수의 복잡성으로 인해 종종 버그를 파악하기가 힘들거나 예상치 못한 동작이 발생할 수 있습니다.
복잡한 로직 또는 환경 구성이 필요한 경우 Cloud Functions 대신 Cloud Run을 사용하는 것이 좋습니다.
환경 관리
개발 및 스테이징 프로젝트를 설정하세요
개발, 스테이징, 프로덕션을 위한 별도의 Firebase 프로젝트를 설정합니다. 스테이징 프로젝트에서 테스트할 때까지 클라이언트 코드를 프로덕션에 병합하면 안 됩니다.
프로덕션 데이터에 대한 팀 액세스를 제한하세요
대규모 팀과 함께 작업하는 경우 사전 정의된 IAM 역할이나 커스텀 IAM 역할을 사용하여 프로덕션 데이터에 대한 액세스를 제한하면 오류 및 위반이 발생하는 결과를 완화할 수 있습니다.
팀에서 개발용 Firebase Local Emulator Suite(권장)을 사용하는 경우 프로덕션 프로젝트에 대한 광범위한 액세스 권한을 부여할 필요가 없을 수도 있습니다.
라이브러리 관리
라이브러리 철자 오류를 주의하고 신규 유지관리 담당자를 관리하세요
프로젝트에 라이브러리를 추가할 때는 라이브러리 이름과 해당 유지관리 담당자를 주의 깊게 살펴보세요. 설치하려는 라이브러리와 유사한 이름의 라이브러리에 악성 코드가 포함될 수 있습니다.
변경사항을 이해하지 않고 라이브러리를 업데이트하지 마세요
업그레이드하기 전에 사용하는 모든 라이브러리의 변경 로그를 검토하세요. 업그레이드를 통해 라이브러리가 향상되며 유지관리 담당자가 여전히 신뢰할 수 있는 사람인지 확인하세요.
개발 또는 테스트 종속 항목으로 워치독 라이브러리를 설치하세요
Snyk와 같은 라이브러리를 사용하여 프로젝트에 안전하지 않은 종속 항목이 있는지 검사하세요.
Cloud Functions 모니터링을 설정하고 라이브러리 업데이트 후 확인하세요
Cloud Functions 로거 SDK를 사용하면 라이브러리 업데이트로 인한 동작을 비롯한 비정상적인 동작을 모니터링하고 알림을 받을 수 있습니다.