비인간 신원은 침해의 원동력입니다: 토큰과 서비스 계정이 계속해서 노출되는 이유

/기술/ 에 의해

API 키, 토큰, 서비스 계정, 워크로드 ID와 같은 비인간 ID는 이제 현대 클라우드 환경에 침투하는 가장 쉬운 방법 중 하나가 되었습니다. 공격자들이 갑자기 천재가 된 것이 아니라, 조직들이 점점 더 기계 간 신뢰에 기반하여 운영되고 있으며, 이러한 신뢰는 종종 지나치게 광범위하고, 오래 지속되며, 제대로 모니터링되지 않기 때문입니다.

최근 보고서에 실린 새로운 분석에 따르면, 수천 개의 컨테이너 이미지와 저장소에서 실수로 보안 비밀 키가 노출되어 프로덕션 시스템에 대한 접근 권한이 조용히 부여되는 대규모 패턴이 나타나고 있습니다. 문제는 개발자가 가끔 실수를 저지르는 것만이 아닙니다. 기본 도구와 인센티브 구조 자체가 이러한 문제를 야기하는 근본적인 원인입니다.쉬운비밀을 전달하기 위해딱딱한당신이 그러지 않았다는 것을 증명하기 위해서요.

이것은 "보이지 않는 침해" 사례입니다. 많은 침해 사고는 익스플로잇이나 요란한 멀웨어 공격으로 시작되지 않습니다. 오히려 깔끔하게 인증되는 토큰에서 시작되는 경우가 많습니다. 모든 것이 정상적으로 보이다가, 나중에야 잘못된 사용자가 해당 토큰을 사용하고 있다는 사실을 깨닫게 되는 것이죠.

“비인간적 정체성”이란 무엇인가 (쉬운 용어로 설명)

비인간 신원(NHI)이란 소프트웨어가 신뢰할 수 있는 주체로 인증할 수 있도록 하는 모든 자격 증명을 의미합니다.

  • 클라우드 액세스 키 및 세션 토큰
  • 서비스 계정 및 워크로드 ID
  • 빌드 파이프라인에서 사용되는 CI/CD 자격 증명
  • SaaS 도구(GitHub, GitLab, Slack, 모니터링 플랫폼)용 토큰
  • 타사 서비스(결제 제공업체, 이메일 제공업체, AI 모델 API)용 API 키

인간 로그인과의 중요한 차이점은 NHI가 일반적으로 다음과 같은 특징을 가진다는 것입니다.

  • 계속 실행
  • 코드 또는 설정에 포함되어 있습니다.
  • 그리고 대부분 다단계 인증(MFA)을 사용하지 않습니다.

그것이 그들을 매력적으로 만드는 요소입니다.

공격자가 유효한 토큰을 획득하면 "침입"할 필요 없이 인증만 하면 됩니다.

왜 지금 상황이 더 악화되고 있는 걸까요?

세 가지 추세로 인해 국민건강보험은 "중요한" 위험에서 "주요 위험"으로 격상되고 있습니다.

1) 소프트웨어 공급망은 그 어느 때보다 규모가 커졌습니다.

최신 앱은 다음 요소들로 구성됩니다:

  • 컨테이너
  • 오픈소스 종속성
  • 인프라스트럭처 코드
  • 수십 개의 SaaS 통합

모든 통합 작업에는 자격 증명이 하나씩 추가됩니다.

2) 자동화는 도처에 존재합니다

조직이 원하는 것:

  • 더 빠른 배포
  • 셀프 서비스 인프라
  • 일시적인 환경

자동화는 유용하지만, 권한을 가진 사용자 계정에 의해 작동됩니다.

3) 자격증명은 그것을 만든 사람보다 더 오래 지속됩니다.

인간은 역할을 바꾸고 떠난다.

하지만 저장소나 컨테이너에 있는 토큰은 다음과 같은 기능을 수행할 수 있습니다.

  • 수개월 또는 수년간 지속됩니다
  • 새 빌드에 복사됩니다
  • 그리고 그것이 존재한다는 사실조차 아무도 기억하지 못하게 된 후에도 오랫동안 유효할 것입니다.

그래서 공격 표면은 조용히 커져간다.

실생활에서 비밀이 새어나가는 방식 (항상 "누군가가 키를 유출했다"는 식은 아니다)

고정관념은 개발자가 커밋하는 것입니다.AWS_SECRET_ACCESS_KEYGitHub에.

그런 일은 여전히 ​​일어납니다. 하지만 많은 정보 유출은 눈에 잘 띄지 않습니다.

  • 컨테이너 레이어에 내장된 토큰
  • 빌드 중에 설정 파일이 이미지에 복사됩니다.
  • 비밀 정보가 포함된 디버그 로그
  • 채팅에서 공유된 "임시" 키를 나중에 코드에 붙여넣었습니다.
  • 잘못 구성된 파이프라인에서 출력되는 CI 변수

컨테이너 이미지가 특히 위험한 이유는 다음과 같습니다.

  • 그것들은 거울처럼 반사됩니다.
  • 캐시됩니다
  • 그것들은 팀들 사이에서 복사됩니다.

저장소에서 키를 삭제하더라도 이전 이미지 레이어에는 키가 남아 있을 수 있습니다.

유출된 토큰이 여러 공격보다 더 위험한 이유는 무엇일까요?

익스플로잇은 시끄럽습니다. 익스플로잇은 종종 경고를 발생시킵니다.

유출된 토큰은 조용히 지나갑니다. 일반적인 사용처럼 보이는 경우가 많습니다.

  • 인증 성공
  • 올바른 API 호출
  • 합법적인 엔드포인트

그렇게 되면 수비수의 문제가 달라집니다.

"공격자"를 탐지하는 대신, 다음을 탐지해야 합니다.

  • 예상치 못한주요한유효한 자격 증명을 사용하여
  • 특이한 장소에서
  • 특이한 시기에
  • 평소와 다른 행동을 하다

이것이 바로 NHI가 많은 조직에게 있어 탐지 공백으로 작용하는 이유입니다.

권한 문제: 토큰은 종종 지나치게 강력한 권한을 지닙니다.

많은 비밀들은 "일단 작동하게 만드는" 지름길로 만들어집니다.

  • 광범위한 클라우드 권한
  • 관리자 수준 API 접근 권한
  • 수명이 긴 키

일단 시스템이 제대로 작동하면 사람들은 그걸 건드리고 싶어 하지 않아요.

이는 위험한 비대칭성을 초래합니다.

  • 사람 계정은 다단계 인증(MFA) 및 모니터링 기능을 가질 수 있습니다.
  • 해당 기계의 신원은 광범위한 접근 권한을 가지며 거의 검증을 받지 않을 수 있습니다.

기기의 신원이 유출되면 파급 효과가 더 커질 수 있습니다.

효과적인 국민건강보험 전략이란 무엇인가 (구체적인 실행 방안)

이 문제는 해결 가능하지만, 국민건강보험을 최우선 보안 자산으로 취급할 경우에만 가능합니다.

1) 단기 자격증을 선호합니다

가능한 경우:

  • 임시 세션 자격 증명을 사용합니다.
  • 토큰을 자주 회전시키세요
  • "만료되지 않음" 키를 사용하지 마세요.

수명이 짧은 토큰은 정보 유출의 이득을 감소시킵니다.

2) 가능한 경우 정적 키를 워크로드 ID로 대체하십시오.

최신 클라우드 환경에서는 다음과 같은 방법으로 워크로드를 인증할 수 있습니다.

  • 인스턴스 ID
  • OIDC 연맹
  • 관리되는 ID

이렇게 하면 정적 키를 저장할 필요성이 줄어듭니다.

3) 환경을 엄격하게 분리하십시오

흔히 발생하는 오류는 다음과 같은 곳에서 동일한 토큰을 사용하는 것입니다.

  • 개발자
  • 각색
  • 생산

토큰은 환경 범위로 지정되어야 합니다.

개발 이미지 유출 시 프로덕션 버전 잠금 해제가 되어서는 안 됩니다.

4) 재고 및 소유권

모든 의미 있는 토큰은 다음을 가져야 합니다:

  • 소유자
  • 목적
  • 예상되는 사용 패턴

토큰에 소유자가 없다면, 그것은 잠재적인 문제로 이어질 수 있는 기술적 부채입니다.

5) 국민건강보험(NHI)의 행태를 인간의 행태를 관찰하듯이 감시하십시오.

긍정적인 신호는 다음과 같습니다.

  • 불가능한 여행 / 특이한 지형
  • 특이한 API 호출 시퀀스
  • 데이터 접속량 급증
  • 새로운 권한이 부여되었습니다
  • 새로운 토큰이 생성되었습니다

목표는 완벽한 탐지가 아니라 조기 탐지입니다.

6) CI/CD를 고위험 아이덴티티 생성 장치로 취급하십시오.

CI 시스템에는 다음과 같은 기능이 자주 포함됩니다.

  • 배포 키
  • 서명 키
  • 클라우드 자격 증명

그들을 가둬라:

  • 최소 특권
  • 분리된 주자들
  • 비밀 정보 은폐 및 로그 유출 방지
  • 제품 배포 단계에 대한 엄격한 승인

팀이 실패하는 일반적인 지점(그리고 이를 피하는 방법)

"가끔 열쇠를 돌려가며 쓴다"는 건 계획이 아니다.

만약 회전이 수동으로 이루어지며 고통스럽다면, 압력을 가해도 회전은 이루어지지 않을 것입니다.

순환 근무를 루틴화하고 자동화하세요.

강제력이 없는 보안 도구는 "감시 쇼"에 불과하다.

저장소에서 비밀 정보를 스캔하는 것은 유용하지만, 그것만으로는 충분하지 않습니다.

또한 다음이 필요합니다:

  • 신속 취소
  • 사용량에 대한 알림
  • 그리고 건설 파이프라인에서의 예방

컨테이너 층 트랩

만약 비밀 정보가 컨테이너 빌드 컨텍스트에 포함되었다면, 다음과 같은 위치에 존재할 수 있다고 가정하십시오:

  • 오래된 이미지
  • 캐시된 레이어
  • CI 아티팩트

해결책은 단순히 "리포지토리 키를 삭제하는 것"이 ​​아닙니다. 해결책은 다음과 같습니다.

  • 비밀을 회전시키세요
  • 이미지를 재구성하고 다시 게시합니다.
  • 가능한 경우 캐시를 무효화합니다.

다음에 볼 콘텐츠

조직이 국민건강보험(NHI)을 개선하고 있는지 추적하려면 다음 사항을 살펴보세요.

  • 단기 ID(OIDC/워크로드 ID) 채택
  • 널리 퍼진 토큰 순환 프로그램
  • 더욱 강력한 CI/CD 경계 제어
  • "유효한 자격 증명 사용"을 주요 원인으로 인정하는 사고 보고서

또한 도구 측면도 주목하세요. 최고의 도구는 "노출된 문자열 탐지"에서 "존재하는 정적 비밀 키의 수를 아예 줄이는 것"으로 바뀔 것입니다.

경제학적 관점: 공격자들이 토큰 사냥을 좋아하는 이유

토큰 사냥 저울.

유효한 계정 정보를 하나 탈취한 공격자는 다음과 같은 일을 할 수 있습니다.

  • 여러 시스템(클라우드 + 소스 제어 + CI)에 액세스
  • 여러 조직에서 동일한 기술을 재사용합니다.
  • 직접 운영하고 싶지 않다면 마켓플레이스에서 접근 권한을 판매하는 방법도 있습니다.

방어자에게 있어 이는 단순히 "우리를 표적으로 삼는 해커"가 위협이 아니라는 것을 의미합니다. 그것은 "재사용 가능한 모든 자격 증명을 통해 이익을 얻는 기계 경제"입니다.

그래서 사후 대응보다는 예방이 훨씬 중요합니다. 키가 고정된 형태로 존재하지 않았다면 나중에 탈취될 염려가 없기 때문입니다.

구체적인 감지 아이디어 (무엇에 대해 알림을 보낼 것인가)

NHI(자연어 처리)에 대한 탐지 기능을 구축하는 경우, 특정 키워드에 얽매이기보다는 행동 변화에 집중해야 합니다.

높은 신호의 예:

  • 서비스 계정은 다음에서 사용됩니다.새로운 국가/ASN이전에는 사용된 적이 없습니다.
  • 일반적으로 하나의 API만 호출하는 토큰이 갑자기 리소스를 열거하거나 대용량 파일을 다운로드합니다.
  • 정상적인 릴리스 기간 외에 작업을 수행하는 CI ID.
  • 서버 워크로드 전용으로 설계되었음에도 불구하고 대화형 사용자 엔드포인트에서 비밀 키가 사용되었습니다.

기본적인 이상 징후 경고만으로도 "은밀한 자격 증명 도용" 패턴을 조기에 포착할 수 있습니다.

콘크리트 경화 아이디어 (적은 노력으로 높은 효과)

다음은 대부분의 팀이 대대적인 재설계 없이도 적용할 수 있는 실질적인 변화입니다.

  • 토큰 범위를 줄입니다.하나의 광범위한 토큰을 여러 개의 세부 범위 토큰으로 분할합니다.
  • 정해진 일정에 따라 교대 근무: 아무런 문제가 없더라도 회전을 시키므로 회전이 근육 기억으로 굳어집니다.
  • 게이트 생산프로덕션 배포용 ID에 대해서는 명시적인 승인이 필요합니다.
  • 빌드에서 평문 비밀 키 차단CI는 명백한 비밀 패턴이 나타날 경우 빌드를 실패시켜야 합니다.

이동할 때마다 누출이 발생하더라도 폭발 반경이 줄어듭니다.

많은 고통을 예방하는 간단한 내부 정책

더 나은 행동을 유도하는 정책을 하나만 원한다면, 바로 이것입니다.

  • 개발자 노트북이나 컨테이너 빌드 환경에는 운영 환경에서 사용할 수 있는 기밀 정보가 없어야 합니다.

그 규칙은 다음과 같은 변화를 가져옵니다.

  • 서비스용 워크로드 ID
  • 개발을 위한 자격 증명 준비
  • 그리고 프로덕션 배포 단계에 대한 명시적 승인

처음엔 좀 귀찮지만, 누수되기 쉬운 경로를 차단해 줍니다.

결론적으로

인간이 아닌 주체는 현대 자동화의 핵심 기반이지만, 동시에 인간을 위해 구축된 보호 장치를 우회하는 경우가 많기 때문에 주요 보안 침해 원인이기도 합니다.

실질적인 기준을 원하신다면, "장기 보유 토큰은 어디에 저장되고, 누가 소유하며, 얼마나 빨리 회수/교체할 수 있는가?"라는 질문에 답할 수 있게 되면, 단순한 희망 사항을 넘어 실질적인 방어 프로그램으로 나아간 것입니다.

실질적인 해결책은 마법 같은 스캐너 하나가 아닙니다. 정적 비밀 키를 최소화하고, 권한을 축소하고, 정기적인 키 교체를 시행하고, 사용자 계정을 모니터링하듯이 시스템 ID를 모니터링하는 프로그램이 필요합니다.

출처

Document Title
Non-human identities are a breach engine: why tokens and service accounts keep getting exposed
Leaked API keys and service-account tokens are a quiet but growing breach driver in cloud environments. Here’s how they leak, why they’re dangerous, and how to harden and detect abuse.
Title Attribute
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
Amaranth-Dragon exploiting a WinRAR flaw shows how fast espionage actors weaponize public bugs
Google teases Pixel 10A: what we know ahead of the February 18 reveal
Page Content
Non-human identities are a breach engine: why tokens and service accounts keep getting exposed
Nature
Climate
/
Technology
/ By
Admin
Non-human identities—API keys, tokens, service accounts, workload identities—are now one of the easiest ways into modern cloud environments. Not because attackers suddenly became geniuses, but because organizations increasingly run on machine-to-machine trust, and that trust is often overbroad, long-lived, and poorly monitored.
A new analysis highlighted in reporting points to a familiar pattern at huge scale: thousands of container images and repositories accidentally exposing secrets that quietly grant access to production systems. The problem isn’t just that developers sometimes make mistakes. The problem is that the default tooling and incentives make it
easy
to ship secrets and
hard
to prove you didn’t.
This is an “invisible breach” story. Many compromises won’t start with an exploit or a loud malware event. They’ll start with a token that authenticates cleanly—so everything looks normal—until you realize the wrong principal has been using it.
What “non-human identities” are (in plain terms)
A non-human identity (NHI) is any credential that lets software authenticate as a trusted actor:
cloud access keys and session tokens
service accounts and workload identities
CI/CD credentials used by build pipelines
tokens for SaaS tools (GitHub, GitLab, Slack, monitoring platforms)
API keys for third-party services (payment providers, email providers, AI model APIs)
The important difference from human logins is that NHIs typically:
run continuously
are embedded in code or config
and often don’t use MFA
That makes them attractive.
If an attacker obtains a working token, they don’t have to “break in.” They authenticate.
Why this is getting worse now
Three trends are pushing NHIs from “important” to “dominant risk”:
1) Software supply chains are bigger than ever
Modern apps are assembled from:
containers
open-source dependencies
infrastructure-as-code
dozens of SaaS integrations
Every integration adds another credential.
2) Automation is everywhere
Organizations want:
faster deploys
self-service infrastructure
ephemeral environments
Automation is good—but it is powered by identities that have privileges.
3) Credentials last longer than the people who created them
Humans change roles and leave.
But a token in a repo or a container can:
persist for months or years
be copied into new builds
and remain valid long after anyone remembers it exists
So the attack surface grows silently.
How secrets leak in real life (it’s not always “someone committed a key”)
The stereotype is a developer committing
AWS_SECRET_ACCESS_KEY
to GitHub.
That still happens. But a lot of leakage is less obvious:
tokens baked into container layers
config files copied into images during build
debug logs containing secrets
“temporary” keys shared in chat and later pasted into code
CI variables printed by misconfigured pipelines
And container images are particularly dangerous because:
they get mirrored
they get cached
they get copied between teams
Even if you delete the key from the repo, the key can remain in old image layers.
Why leaked tokens are more dangerous than many exploits
Exploits are noisy. They often trigger alerts.
Leaked tokens are quiet. They often look like normal usage:
successful authentication
correct API calls
legitimate endpoints
That changes the defender’s problem.
Instead of detecting “an attacker,” you have to detect:
an unexpected
principal
using valid credentials
from unusual locations
at unusual times
doing unusual actions
This is why NHIs are a detection gap for many organizations.
The privilege problem: tokens are often too powerful
A lot of secrets are created as “get it working” shortcuts:
broad cloud permissions
admin-level API access
long-lived keys
And once the system works, people don’t want to touch it.
This creates a dangerous asymmetry:
a human account might have MFA and monitoring
the machine identity might have broad access and little scrutiny
When the machine identity leaks, the blast radius can be bigger.
What a good NHI strategy looks like (concrete practices)
This is solvable, but only if you treat NHIs as first-class security assets.
1) Prefer short-lived credentials
Where possible:
use temporary session credentials
rotate tokens frequently
avoid “never expires” keys
Short-lived tokens reduce the payoff of leaks.
2) Replace static keys with workload identity where you can
In modern cloud setups, you can often authenticate workloads via:
instance identity
OIDC federation
managed identity
This reduces the need to store static keys.
3) Separate environments strictly
A common failure is using the same token across:
dev
staging
production
Tokens should be environment-scoped.
If a dev image leaks, it shouldn’t unlock prod.
4) Inventory and ownership
Every meaningful token should have:
an owner
a purpose
an expected usage pattern
If a token has no owner, it is technical debt waiting to become an incident.
5) Monitor NHI behavior like you monitor human behavior
Good signals include:
impossible travel / unusual geographies
unusual API call sequences
spikes in data access
new permissions granted
new tokens created
The goal is not perfect detection; it’s early detection.
6) Treat CI/CD as a high-risk identity factory
CI systems frequently hold:
deployment keys
signing keys
cloud credentials
Lock them down:
least privilege
separated runners
secret masking and prevention of log leaks
strict approvals for production deploy steps
Where teams usually fail (and how to avoid it)
“We rotate keys sometimes” isn’t a plan
If rotation is manual and painful, it won’t happen under pressure.
Make rotation routine and automated.
Security tools without enforcement become “monitoring theater”
Scanning repositories for secrets is useful, but it’s not enough.
You also need:
rapid revocation
alerts on usage
and prevention in build pipelines
The container layer trap
If secrets ever entered a container build context, assume they may exist in:
old images
cached layers
CI artifacts
The fix is not only “delete the repo key.” It’s:
rotate the secret
rebuild and republish images
invalidate caches where possible
What to watch next
If you want to track whether organizations are improving on NHIs, look for:
adoption of short-lived identity (OIDC/workload identity)
widespread token rotation programs
stronger CI/CD boundary controls
incident reports that acknowledge “valid credentials used” as a primary cause
Also watch the tooling side: the best tools will shift from “detect exposed strings” to “reduce the number of static secrets that exist at all.”
The economics: why attackers love token hunting
Token hunting scales.
An attacker who steals one working credential can often:
access multiple systems (cloud + source control + CI)
reuse the same technique across many organizations
and sell access in marketplaces if they don’t want to operate it themselves
For defenders, this means the threat isn’t just “a hacker targeting us.” It’s “a machine economy that profits from any reusable credential.”
That’s why prevention is more valuable here than response. If the key never existed in static form, it can’t be harvested later.
Concrete detection ideas (what to alert on)
If you’re building detections for NHIs, focus on behavior changes rather than magic keywords.
High-signal examples:
A service account used from a
new country/ASN
it never used before.
A token that normally only calls one API suddenly enumerates resources or downloads large volumes.
A CI identity performing actions outside the normal release window.
Secrets used from interactive user endpoints when they were intended only for server workloads.
Even basic anomaly alerts can catch the “quiet credential theft” pattern early.
Concrete hardening ideas (low effort, high leverage)
These are practical changes most teams can make without a massive redesign:
Reduce token scope
: split one broad token into several narrowly scoped tokens.
Rotate on schedule
: rotate even when nothing is “wrong,” so rotation becomes muscle memory.
Gate production
: require explicit approval for production deploy identities.
Block plaintext secrets in builds
: CI should fail builds when obvious secret patterns appear.
Each move shrinks blast radius even if a leak still occurs.
A simple internal policy that prevents a lot of pain
If you want one policy that forces better behavior, it’s this:
No production-capable secrets in developer laptops or in container build contexts.
That rule drives changes like:
workload identity for services
staging credentials for development
and explicit approvals for production deployment steps
It’s annoying at first, but it cuts off the easiest leak paths.
Bottom line
Non-human identities are the backbone of modern automation—and also a major breach driver because they often bypass the protections we’ve built for humans.
If you want a practical threshold: once you can answer “where do our long-lived tokens live, who owns them, and how quickly can we revoke/rotate them,” you’ve moved from wishful thinking to a real defense program.
The practical fix is not one magic scanner. It’s a program: minimize static secrets, shrink privileges, make rotation routine, and monitor machine identities like you monitor user accounts.
Sources
https://www.bleepingcomputer.com/news/security/the-double-edged-sword-of-non-human-identities/
←
Previous Post
Next Post
→
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
Amaranth-Dragon exploiting a WinRAR flaw shows how fast espionage actors weaponize public bugs
Google teases Pixel 10A: what we know ahead of the February 18 reveal
Leaked API keys and service-account tokens are a quiet but growing breach driver in cloud environments. Here’s how they leak, why they’re dangerous, and how to harden and detect abuse.
Document Title
Page not found - Florin.blog
Image Alt
Florin.blog
Title Attribute
Florin.blog » Feed
RSD
Skip to content
Placeholder Attribute
Search...
Page Content
Page not found - Florin.blog
Skip to content
Home
Blog
Garden Decor
Indoor
Main Menu
This page doesn't seem to exist.
It looks like the link pointing here was faulty. Maybe try searching?
Search for:
Search
Quick Links
Outdoors
About
Contact
Explore
Bestsellers
Hot deals
Best of The Year
Featured
Gift Cards
Help
Privacy Policy
Disclaimer
: As an Amazon Associate, we earn from qualifying purchases — at no extra cost to you.
Florin.blog
Florin.blog » Feed
RSD
Search...
한국어