접근 모니터링을 통해 사용자는 Teleport 클러스터의 접근 패턴을 이해하고 분석할 수 있습니다.

클러스터에서 접근 모니터링이 활성화되면 Teleport는 다양한 입력 소스에서 데이터를 수집하고, 클러스터 내 사용 패턴을 강조하는 그래픽 보고서를 작성하며, 사용자가 자동화된 대응 작업을 만들 수 있도록 하는 백그라운드 서비스를 실행합니다.

접근 모니터링의 주요 데이터 소스는 Teleport 감사 로그입니다. 기본적으로 Teleport는 위험한 사용 패턴(예: MFA 없는 SSH 또는 데이터베이스 세션)을 나타내는 이벤트를 감사 로그에서 검색하고 제안된 조치에 대한 권장 사항을 사용자에게 제공하는 보고서를 포함합니다.

사용자는 감사 로그를 쿼리하여 자체 커스텀 접근 모니터링 쿼리를 작성할 수 있습니다.

전제 조건#

• A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

• The tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

     $ TELEPORT_DOMAIN=
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     

  2. Follow the instructions for your platform to install tctl and tsh clients:

• 자체 호스팅 Teleport의 경우 Amazon Athena Backend가 필요합니다.

구성#

auth_service:
  access_monitoring:
    enabled: true
    # AWS role ARN that Teleport will assume to execute Athena SQL queries.
    # The Teleport role should be configured with a trust relationship and should be able to assume this role.
    role_arn: arn:aws:iam::123456789012:role/AccessMonitoringRole
    # S3 bucket where Access Monitoring reports will be stored.
    report_results: s3://audit-long-term/report_results
    # (Optional) Athena workgroup used by Access Monitoring
    # queries (if not set, the default primary workgroup will be used).
    workgroup: access_monitoring_workgroup

$ terraform apply
...
 access_monitoring:
   enabled: true
   report_results: s3://long-term/report_results
   role_arn: arn:aws:iam::123456789012:role/AccessMonitoringRole
   workgroup: access_monitoring_workgroup

접근 모니터링 RBAC 권한#

접근 모니터링 인터페이스에 접근하려면 사용자에게 security_report 및 audit_query 리소스에 대한 list, read, use 동사를 허용하는 역할이 있어야 합니다. 사전 설정된 auditor 역할은 기본적으로 이러한 권한을 가지고 있습니다. 또는 다음 권한으로 커스텀 역할을 만들 수 있습니다:

kind: role
metadata:
  name: my-role
spec:
  allow:
    rules:
    - resources:
      - security_report
      - audit_query
      verbs:
      - list
      - read
      - use

쿼리 편집기#

접근 모니터링의 쿼리 편집기는 사용자가 감사 로그를 대화형으로 쿼리하고 보고서를 생성하는 인터페이스를 제공합니다. 사용자는 이러한 뷰에 대한 커스텀 SQL 쿼리를 작성하여 관계형 데이터베이스 쿼리와 유사한 커스텀 보고서를 만들 수 있습니다.

쿼리 편집기 내에서 사용자는 Teleport가 캡처한 감사 이벤트를 나타내는 여러 SQL 뷰에 접근할 수 있습니다. 사용 가능한 SQL 뷰 목록:

쿼리 편집기에 접근하려면 Teleport UI의 Access Monitoring 섹션으로 이동하고 Query Editor 탭을 클릭합니다.

SQL 쿼리 예시#

• /etc/passwd 파일과 관련된 SSH 명령을 실행한 고유 사용자를 쿼리합니다:

SELECT
  DISTINCT user
FROM
  exec
WHERE
  command LIKE '%/etc/passwd%';

• 다양한 이벤트 날짜에 걸쳐 각 사용자 인증서와 관련된 고유 IP 주소의 수를 선택합니다:

SELECT
  event_date,
  identity_user AS user,
  COUNT(DISTINCT cert_create.identity_client_ip) AS unique_ip_count
FROM
  cert_create
GROUP BY
  event_date,
  identity_user
ORDER BY
  event_date;

• 두 개 이상의 다른 IP 주소에서 Teleport 클러스터와 상호 작용한 사용자를 선택합니다:

SELECT * FROM (SELECT
  event_date,
  identity_user AS user,
  COUNT(DISTINCT cert_create.identity_client_ip) AS unique_ip_count
FROM
  cert_create
GROUP BY
  event_date,
  identity_user
ORDER BY
  event_date) AS data WHERE unique_ip_count > 1;

• 'admin-annie' 사용자가 사용한 모든 고유 IP 주소를 표시합니다:

SELECT
  DISTINCT identity_client_ip
FROM
  cert_create
WHERE identity_user = 'admin-annie'

• 접근 요청 및 검토를 표시합니다:

SELECT
  *
FROM
  access_request_create, access_request_review
WHERE
  access_request_create.id = access_request_review.id

• 접근 요청 및 검토에 대한 세부 정보를 표시합니다:

SELECT
  request.user, request.reason, request.roles, request.resource_ids, review.reviewer, review.state
FROM
  access_request_create as request, access_request_review as review
WHERE
  request.id = review.id

접근 모니터링 보고서#

접근 모니터링은 여러 사전 빌드된 보고서를 제공합니다.

권한 있는 접근 보고서#

Privileged Access Report는 인프라 전반의 취약한 보안 이벤트를 식별하는 데 유용한 인사이트를 제공합니다. 이 보고서를 통해 다음과 같은 취약한 보안 이벤트를 식별할 수 있습니다:

취약한 보안을 가진 데이터베이스 세션#

다음 쿼리는 접근 요청, MFA, 가장(impersonation), 신뢰할 수 있는 장치 식별이 없는 세션과 같은 취약한 보안을 가진 데이터베이스 세션을 식별합니다.

SELECT
    event_date,
    count(*) as count,
    user
FROM
    db_session_start
WHERE
    CARDINALITY(access_requests) IS NULL
AND
    with_mfa IS NULL
AND
    impersonator IS NULL
AND
    trusted_device_device_id IS NULL
GROUP BY
    event_date,
    user
ORDER BY
    event_date

제안: 접근 요청, 장치 신뢰, 세션별 MFA를 설정하세요.

취약한 보안을 가진 SSH 세션#

다음 쿼리는 접근 요청, MFA, 가장, 신뢰할 수 있는 장치 식별이 없는 세션과 같은 취약한 보안을 가진 SSH 세션을 식별합니다.

SELECT
    event_date,
    count(*) as count,
    user
FROM
    session_start
WHERE
    CARDINALITY(access_requests) IS NULL
AND
    proto='ssh'
AND
    with_mfa IS NULL
AND
    impersonator IS NULL
AND
    trusted_device_device_id IS NULL
GROUP BY
    event_date,
    proto,
    user
ORDER BY
    event_date

제안: 접근 요청, 장치 신뢰, 세션별 MFA를 설정하세요.

취약한 보안을 가진 Kubernetes API 호출#

다음 쿼리는 접근 요청, MFA, 가장, 신뢰할 수 있는 장치 식별이 없는 세션과 같은 취약한 보안을 가진 Kubernetes 세션을 식별합니다.

SELECT
    event_date,
    count(*) as count,
    user
FROM
    kube_request
WHERE
    CARDINALITY(access_requests) IS NULL
AND
    with_mfa IS NULL
AND
    impersonator IS NULL
AND
    trusted_device_device_id IS NULL
GROUP BY
    event_date,
    user
ORDER BY
    event_date

제안: 접근 요청, 장치 신뢰, 세션별 MFA를 설정하세요.

권한 있는 Postgres 세션#

다음 쿼리는 'postgres' 사용자가 시작한 권한 있는 PostgreSQL 세션을 식별합니다.

SELECT
	event_date,
	COUNT(*) AS count,
	user
FROM
    db_session_start
WHERE
    db_protocol='postgres' and db_user='postgres'
GROUP BY
    event_date,
    user
ORDER BY
    event_date

제안: 데이터베이스 연결을 덜 권한 있는 데이터베이스 사용자로 다운그레이드하세요.

Kube Exec#

다음 쿼리는 Kubernetes exec 사용을 식별합니다.

SELECT
    event_date,
    count(*) as count,
    user
FROM
    exec
WHERE
    proto='kube'
GROUP BY
    event_date,
    proto,
    user
ORDER BY
    event_date

제안: kube exec 사용을 제거하세요.

장기 인증서#

다음 쿼리는 인증서 만료 시간이 1일 이상인 장기 인증서를 식별합니다.

SELECT DISTINCT
    event_date,
    COUNT(*) AS count,
    identity_user AS user
FROM
    cert_create
WHERE
    from_iso8601_timestamp(identity_expires) - from_iso8601_timestamp(time) > INTERVAL '1' DAY
GROUP BY
    event_date,
    identity_user
ORDER BY
    event_date

제안: 하루 근무 시간보다 짧은 단기 인증서를 사용하세요. 자동화에 대한 단기 인증서를 얻으려면 머신 및 워크로드 아이덴티티를 확인하세요.

장기 조인 토큰#

다음 쿼리는 토큰 만료 시간이 1일 이상인 장기 조인 토큰을 식별합니다.

SELECT
    event_date,
    COUNT(*) as count,
    node_name,
    host_id
FROM
    instance_join
WHERE
    FROM_ISO8601_TIMESTAMP(token_expires) - FROM_ISO8601_TIMESTAMP(time) > INTERVAL '1' DAY
GROUP BY
    event_date,
    node_name,
    host_id
ORDER BY
    event_date

제안: 가능한 경우 단기 토큰을 사용하거나 위임된 조인을 사용하여 손상 위험을 줄이세요.

Root SSH 세션#

다음 쿼리는 'root' 사용자가 시작한 SSH 세션을 식별합니다.

SELECT
    event_date,
    COUNT(*) as count,
    user
FROM
    session_start
WHERE
    login='root'
GROUP BY
    event_date,
    user
ORDER BY
    event_date

제안: SSH 세션에 root를 사용하지 말고, sudo 권한을 가진 사용자로 접근을 다운그레이드하세요.

시스템 Kubernetes API 호출#

다음 쿼리는 'system:master' 그룹의 사용자가 시작한 Kubernetes API 호출을 식별합니다.

SELECT
	event_date,
	COUNT(*) as count,
	user
FROM
    kube_request
WHERE
    CONTAINS(kubernetes_groups, 'system:masters')
GROUP BY
    event_date,
    user
ORDER BY
    event_date

제안: Kubernetes API 호출에 system:masters 그룹을 사용하지 말고, 대신 view 또는 edit으로 다운그레이드하세요.

CLI에서 접근 모니터링 감사 쿼리 실행#

tctl audit query exec 명령을 사용하여 커스텀 감사 쿼리를 실행합니다:

$ tctl audit query exec 'select event_time,identity_user from cert_create order by event_date limit 1;'
[
    {
        "data": [
            "event_time",
            "identity_user"
        ]
    },
    {
        "data": [
            "2024-03-20 12:12:03.374",
            "alice"
        ]
    }
]

쿼리 결과는 배열의 JSON 배열로 반환됩니다. 첫 번째 배열에는 열 이름이 포함되고, 이후 배열에는 쿼리 결과가 포함됩니다.

기본적으로 tctl audit query exec는 지난 7일 동안을 검색합니다. --days=N 플래그로 다른 기간을 지정할 수 있습니다.