보안, secrets 및 안전한 운영

프로젝트 로컬 secrets

Lino는 생성된 애플리케이션에 필요한 로컬 secrets를 자동으로 등록합니다. 데이터베이스, Redis, RabbitMQ 비밀번호, JWT 키, API keys 및 기타 민감한 값은 버전 관리 파일이 아니라 애플리케이션의 User Secrets에 보관됩니다.

lino secret list
lino secret set
lino secret remove
lino secret clear

이 명령은 유지보수에도 유용합니다. secret list는 구성된 키를 감사할 때, secret set은 로컬 값을 변경하거나 등록할 때, secret remove는 키를 삭제할 때, secret clear는 프로젝트의 모든 로컬 secrets를 지울 때 사용합니다.

이 흐름은 생성된 프로젝트에 통합되어 있습니다. Redis, RabbitMQ, 인증, 권한 부여, SMTP, API keys 또는 download tokens 같은 리소스를 추가할 때 Lino는 민감한 값을 소스 코드 밖에 유지하고, 애플리케이션이 이를 환경 구성으로 받을 수 있도록 준비합니다.

필요한 경우 dotnet user-secrets list 또는 동등한 Aspire 리소스처럼 .NET 및 Aspire 플랫폼 도구로 로컬 secrets를 확인할 수도 있습니다. Lino 명령은 생성된 프로젝트의 맥락에서 이 흐름을 더 직접적으로 만들기 위해 존재합니다.

Aspire의 매개변수

Aspire AppHost는 데이터베이스, Redis, RabbitMQ, API, worker, web app 같은 리소스를 조정합니다. 생성된 프로젝트에서 Lino는 민감한 값을 Aspire 매개변수로 등록하여 애플리케이션이 이 값을 소스 코드의 고정 데이터가 아니라 외부 의존성으로 다루도록 합니다.

여기에는 데이터베이스, Redis, RabbitMQ 비밀번호와 로컬 인프라에 필요한 기타 값이 포함됩니다. AppHost는 Aspire의 secret 모델을 사용하여, 예를 들어 sensitive로 표시된 매개변수를 통해 이러한 값을 해당 리소스에 전달합니다.

실질적인 이점은 secret이 구성 파일 속에 묻힌 세부 정보가 아니라 솔루션 실행 모델의 일부가 된다는 것입니다. Aspire를 통해 애플리케이션을 실행하면 각 서비스는 필요한 의존성을 받고, 사용자가 각 프로젝트에 비밀번호를 수동으로 복사할 필요가 없습니다.

이 설계는 deploy에도 도움이 됩니다. Aspire가 아티팩트를 게시할 때도 이러한 매개변수의 필요성은 계속 존재합니다. 예를 들어 Docker Compose에서는 올바른 환경에서 채워야 할 placeholders와 환경 파일이 나타날 수 있습니다. 다른 targets에서도 같은 원칙이 민감한 구성을 플랫폼으로 전달하는 방식을 안내합니다.

Rate limiting

Rate limiting은 악용, brute force, 부적절한 리소스 소비를 줄입니다. Lino는 이미 기본 policies를 구성하고 생성된 endpoints에 helpers를 적용하여 public, authenticated, internal, sensitive API가 사용 제한 없이 만들어지지 않도록 합니다.

API가 올바르게 인증하더라도 대량 호출 악용을 겪을 수 있으므로 중요합니다. Login, refresh token, 가입, 비밀번호 복구는 민감한 흐름입니다. 기본적으로 Lino는 이를 일반 endpoints와 분리하여 더 보수적인 제한을 갖게 합니다.

• 새 endpoints를 만들 때 생성된 policies를 사용하세요.
• 민감한 endpoints와 일반 endpoints에 서로 다른 제한을 유지하세요.
• 필요한 경우 rate limiting을 인증, 검증, bot 보호와 함께 사용하세요.
• 제한을 초과했을 때 429 Too Many Requests를 예상 응답으로 처리하세요.

JWT 보안

인증이 추가되면 Lino는 JWT를 발급, 읽기, 검증하기 위한 기반을 생성하면서 서명 키를 소스 코드 밖에 유지합니다. token은 사용자를 식별하고 필수 claims를 담지만 JWT를 휴대용 데이터베이스로 만들지는 않습니다.

• 개발 중에는 서명 키를 User Secrets에, 운영 환경에서는 안전한 provider에 보관하세요.
• 프로젝트에 구성된 issuer, audience, 만료 및 알고리즘 검증을 유지하세요.
• 인증된 흐름에 필요한 claims만 포함하세요.
• multi-tenancy에서는 Lino가 이미 제공하는 user 및 tenant context를 사용하세요.

JWT 서명 키는 중요한 secret이며, Lino는 이미 이 값을 민감한 구성으로 취급합니다. 새 환경, pipeline 또는 deploy를 만들 때도 같은 규칙을 유지하세요. 키는 commit, Docker image, log, 공개 파일 또는 실제 구성 예시에 나타나면 안 됩니다.

JWT는 도메인 권한 부여를 대체하지도 않습니다. claims는 결정을 돕지만, 중요한 작업은 여전히 현재 상태, 사용자 상태, 활성 권한 및 요청 context를 고려해야 합니다. 생성된 부분은 기반을 제공합니다. 시스템을 발전시킬 때의 책임은 이 흐름을 우회하는 지름길을 만들지 않는 것입니다.

API keys 및 download tokens

Lino는 API keys와 임시 tokens를 제한된 scope의 credentials로 취급합니다. 흐름이 파일, 패키지 또는 통합에 대한 임시 접근을 허용해야 할 때, 생성된 기반은 넓은 credentials를 재사용하는 대신 짧고 구체적인 tokens를 선호합니다.

• links와 임시 tokens에는 짧은 만료 시간을 사용하세요.
• 흐름에 해당 context가 있으면 token을 user, tenant, resource와 연결하세요.
• 민감한 아티팩트 접근이 포함되면 감사를 위해 사용을 기록하세요.
• resource 또는 permission이 변경되면 tokens를 취소하세요.

키로 보호되는 API는 Lino가 생성한 권한 부여 및 rate limiting 모델을 사용합니다. 통합 자동화를 위해 만든 키가 관리 호출의 자유 이용권이 되어서는 안 되며, 임시 download token이 인증된 사용자의 permissions를 대체해서도 안 됩니다.

새 download 또는 통합 흐름을 만들 때도 같은 개념을 유지하세요. 명시적 scope, 만료, 유용한 metadata, 적절한 rate limiting policy입니다. 이렇게 하면 임시 접근은 시스템을 떠도는 느슨한 credential이 아니라 감사 가능하고 예측 가능한 상태로 유지됩니다.

운영 환경의 secret providers

User Secrets는 로컬 개발 문제를 해결합니다. 운영 환경에서는 플랫폼의 안전한 provider를 사용하여 같은 분리를 유지하세요. Azure Key Vault, AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Kubernetes Secrets 또는 orchestrator가 보호하는 환경 변수를 사용할 수 있습니다.

Lino는 애플리케이션이 코드 외부에서 민감한 구성을 받을 수 있도록 준비합니다. 운영 환경으로의 전환은 환경 결정입니다. 이름과 매개변수는 계속 존재하지만, 값은 인프라에서 사용하는 vault, pipeline 또는 orchestrator에서 오게 됩니다.

운영 환경에서는 rotation, 환경별 분리, 애플리케이션별 권한, 접근 감사 같은 운영 관행도 필요합니다. User Secrets는 이러한 통제를 대체하지 않습니다. secrets를 리포지토리에 넣지 않고 로컬 경험을 지원합니다.

• 환경별로 분리: development, staging, production은 credentials를 공유하면 안 됩니다.
• 애플리케이션별로 분리: 각 서비스는 필요한 secrets만 받아야 합니다.
• Rotation 계획: JWT keys, SMTP, API keys, 데이터베이스 비밀번호에는 교체 절차가 필요합니다.
• 접근 감사: 플랫폼에서 secrets를 읽거나 변경할 수 있는 사람을 기록하세요.