AWS OpenSearch(오픈서치)는 핵심 기능을 확장하기 위해 다양한 Plugin을 제공합니다. 이를 통해 운영 환경에 맞게 안정적이고 효율적인 기능을 추가할 수 있습니다. 그중에서도 Alerting Plugin 은 조건 기반 탐지와 알림 기능을 제공하며, 보안 모니터링이나 장애 대응 같은 영역에서 자주 활용됩니다. 특정 이벤트를 실시간으로 감시하고, 정의한 조건을 만족할 경우 자동으로 알림을 발생시켜 운영자의 대응 속도를 높일 수 있습니다.
이번 글을 통해서 Alerting Plugin의 주요 구성 요소와, 실제 적용 과정에서 고려해야 할 부분을 함께 살펴보겠습니다.
보안기능의 기본은 특정 조건에 대한 탐지설정을 하고 설정한 탐지 조건에 만족하는 데이터를 찾게 되면 원하는 형태로 알림을 발생시키는 것입니다.
Alerting 은 Opensearch 내에 데이터를 탐지 대상으로 하여 기본 탐지 기능을 안정적으로 제공하는 plugin 입니다. Opensearch 문서에서는 대략적으로 아래 키워드로 설명 하고 있습니다.
- Monitor: 검색조건에 해당하는 쿼리를 작성하고, 실행주기를 설정합니다. 여기에서 정의된 쿼리의 실행 결과는 Trigger 의 입력 데이터로 사용됩니다.
- Trigger: 입력되는 쿼리 결과를 기준으로 실제 행위를 발생시키는 조건을 정의합니다.
- Alert: Trigger 에서 정의된 조건이 만족하는 경우 Alert 이라는 이벤트를 생성합니다.
- Action: Alert 이 발생했을 때 수정행 할 작업을 정의합니다.
- Notification: Alert 이 발생했을 때 전송되는 알림 메시지를 정의합니다.
Alerting 기능은 Opensearch 1.1.0 버전부터 제공된다고 되어 있지만, 알림(Notification) 기능이 추가되는 2.0 이후 버전부터 활용성이 높아졌다고 생각되네요. 개발의 편의성이나 시각적인 결과를 원한다면 OpenSearch Dashboards에 도입되는 2.9 버전 부터가 OpenSearch Dashboards 에 도입되기 때문에 시각적인 결과확인이 가능하여 개발이나 테스트 시에 도움이 많이 될 수 있습니다.
Openserach 가 설치되어 있다면 다음 방법으로 plugin 상태를 확인해 볼 수 있는데요.
curl -X GET http://localhost:9200/_plugins/_alerting
결과
opensearch-alerting 2.16.0.0
opensearch-notifications 2.16.0.0
opensearch-notifications-core 2.16.0.0
실제 사용해봤던 버전은 2.10, 2.16 으로 기능상으로 큰 차이는 없었기에 적당한 버전을 선택하여 사용하면 될 것 같네요.
아래는 openserach-dashboard 명령어로 설치된 plugin 리스트를 확인한 결과입니다.
./opensearch-dashboards-plugin list --allow-root
alertingDashboards@2.16.0.0
anomalyDetectionDashboards@2.16.0.0
assistantDashboards@2.16.0.0
customImportMapDashboards@2.16.0.0
ganttChartDashboards@2.16.0.0
indexManagementDashboards@2.16.0.0
mlCommonsDashboards@2.16.0.0
notificationsDashboards@2.16.0.0
observabilityDashboards@2.16.0.0
queryWorkbenchDashboards@2.16.0.0
reportsDashboards@2.16.0.0
searchRelevanceDashboards@2.16.0.0
securityAnalyticsDashboards@2.16.0.0
securityDashboards@2.16.0.0
아래는 Opensearch Dashboard 에서 설치된 plugin 을 메뉴로 확인상태 입니다.
이처럼 필요한 플러그인을 적절한 버전으로 설치했다면, 이제 Alerting의 핵심 기능인 Monitor 와 Trigger 설정 방법을 살펴보겠습니다.
실제로 탐지를 수행하고 alert을 발생시키기 위한 trigger의 입력 값이 되는 검색조건과 실행 주기를 설정하는 부분입니다. Monitor 는 Alerting 의 출발점이자 이후 Trigger, Alert, Action 으로 이어지는 전체 탐지 프로세스의 기반이 되는 구성 요소입니다.
아래와 같이 몇 가지 검색조건을 구분하는 기능을 제공하는데, Per Query Monitor, Per Bucket Monitor에 대해서 먼저 알아보겠습니다.
설정한 쿼리 결과의 개수를 그대로 Trigger 조건의 입력 값으로 사용하도록 처리하는 방식이기 때문에 기본적이면서 단순 조건을 처리할 때 주로 사용하는 방식입니다.
예를 들어 시스템 로그를 대상으로 특정 사용자에 대한 로그인 실패 이력을 조건으로 건다고 했을때 아래와 같은 쿼리가 가능합니다.
{
"size": 0,
"query": {
"bool": {
"must": [
"match_phrase": {
"userid": {
"query": "root",
"slop": 0
}
},
"action": {
"query": "failed_password",
]
],
"filter": [
"range": {
"@timestamp": {
"from": "now-30m",
"to": "now"
쿼리에 만족하는 조건이 있다면 아래와 같은 결과가 나타납니다.
"_shards": {
"total": 9,
"failed": 0,
"successful": 9,
"skipped": 0
"hits": {
"hits": [],
"total": {
"value": 4,
"relation": "eq"
"max_score": null
Per Query Monitor 은 위와 같은 결과가 나왔을 경우 trigger 조건에 만족한다면 단일 alert 이 한 개 발생하는 방식입니다.
이 방식은 쿼리에 Aggregation 를 설정하여 Bucket 단위 별로 trigger 조건을 검사하고 alert 을 발생시키는 방식입니다.
Per Query Monitor 과 동일한 조건의 쿼리에 아래와 같은 Aggregation query 가 추가되는 형태입니다.
"aggregations": {
"by_agg": {
"terms": {
"field": "host.keyword",
"order": [
"_count": "desc"
"_key": "asc"
host 라는 필드로 group by 와 같은 집계를 하면 결과는 host 단위의 buckets 가 생성되고 각각의 bucket 에 개수가 포함되게 됩니다. 각각의 bucket 에 포함된 개수가 trigger 조건에 만족한다면 만족하는 만큼 alert 이 발생하게 되는데 이 부분이 Per Query Monitor 방식과 차이점이 되겠습니다.
...
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
"doc_count": 2,
"key": "testhostname1"
"key": "testhostname2"
curl -X POST "https://localhost:9200/_plugins/_alerting/monitors/_search?pretty=true" -k -H "Content-Type: application/json" -d '{}'
아래와 같이 등록한 monitor 정보를 JSON 포맷으로 조회할 수 있습니다.
Monitor 관련 몇 가지 API를 소개합니다. Create, Update 등 기본적인 기능 외에 설정한 Monitor 를 실행 시킬 수 있는 Monitor RUN API 도 제공 됩니다. 필요에 따라서 자신의 시스템에서 직접 실행시키는 로직을 구현해 볼 수 도 있을 것 같구요. 설정 내용을 미리 시뮬레이션 해서 결과를 테스트 해볼 수 있는 기능으로 활용해도 좋을 것 같습니다.
Monitor Create
POST _plugins/_alerting/monitors
Monitor Update
PUT _plugins/_alerting/monitors/<monitor_id>
Monitor Delete
DELETE _plugins/_alerting/monitors/<monitor_id>
Monitor Run
POST _plugins/_alerting/monitors/<monitor_id>/_execute
Trigger 는 Monitor 에 설정한 쿼리의 결과를 입력으로 Alert 을 발생 시킬 조건을 설정하는 과정입니다. 이 부분도 Per Query Monitor 과 Per Bucket Monitor 방식이 차이가 있습니다.
Per Query Monitor는 쿼리의 결과가 단순 개수(hits)이기 때문에 개수 연상에 대한 true, false 로 결과를 얻습니다. 물론 결과가 true 인 경우에만 alert 이 발생하는 조건이 되겠죠.
Per Bucket Monitor 방식은 개수 조건을 설정 하는 건 동일하지만 Aggregation 문에 정의된 key 명을 parent_bucket_path 에 맞춰 줘야 된다는게 다른 점입니다.
Trigger condition 에서 설정한 조건이 만족한다면 bucket 단위로 결과 구해지게 됩니다.
[
"doc_count": 3,
"doc_count": 4,
만약 실제로 이런 결과가 나왔다면 alert testhostname1, testhostname2 두 개의 alert 이 발생하게 됩니다.
Monitor -> Trigger 조건이 만족하였다면 Alert 이라는 단위의 알림이 생성됩니다. Alert 은 Action 과 연계되었을 때 외부로 통보 등의 전달 기능을 수행할 수가 있고, 이런 연계 설정이 없다면 단순히 alert 이라는 데이터가 하나 신규로 생성되었다고 보면 됩니다.
Opensearch Dashboard Alerts 메뉴에서는 아래와 같이 발생된 Alert 이 조회 됩니다.
Alert 단위 별로 구체적으로 확인할 수 있는 방법은 없는 것 같고, Opensearch Dashboard 에서는 조회할 수 있는 정보는 이 정도가 전부인 것 같습니다.
Alert은 발생 시점부터 Completed 될 때까지 아래 상태로 관리가 됩니다.
- Active
조건이 만족하여 발생된 상태이고 아무런 처리가 되지 않은 상태라고도 합니다.
- Acknowledged
관리자가 확인했다 정도의 의미를 부여할 수 있을 것 같은데요. 이 상태로 변경된 후부터 조건이 만족 했는데도 Alert 이 발생하지 않는 것처럼 보여질 수도 있습니다. 하지만 특정 시점이 되면 다시 Alert 이 발생하게 되는데 좀 애매한 운영 상태라고 보여집니다.
정확한 것은 이 상태 이후 실제 Alert을 발생시키는 조건이 해제 되었다가 다시 조건이 만족하게 된다면 Alert 이 발생하게 됩니다. Alert이 계속 발생되는 조건이라면 계속 Acknowledged 상태가 유지 되는 거라서 추가 Alert 이 발생되지 않는다는 오해에 소지가 있을 수도 있겠네요.
1번과 같이 Acknowledged 상태라도 조건이 만족하고 있는 상태라면 기존 상태가 유지가 되고, 2번 처럼 조건이 불만족 상태가 되면 상태는 Completed 상태가 되어 Alert 은 종료 처리됩니다.
3번처럼 이후 다시 조건이 만족한다면 새로운 Alert 이 발생하게 됩니다.
- Completed
Alert이 발생하는 조건 즉 Trigger 조건이 만족하지 않는 경우 기존 발생된 Alert 상태는 Completed 상태로 전환됩니다. 이후 다시 조건이 만족한다면 새로운 Alert 이 발생하게 됩니다.
개발 중에 이슈 사항 중 하나였다면 Completed 상태를 관리자가 임의로 변경할 수 없다는 것입니다. Alerting 시스템의 철학인지는 모르겠지만 상태 변경은 Acknowledged 만 가능하다는 것입니다.
즉 Completed는 Alerting 자체에서 조건의 만족 상태에 따라 변경해 주는 상태이고, 개발중인 시스템에서 Completed 상태를 별도로 운영하기 위해서는 자체적인 상태 처리 로직이 추가 되어야 됩니다.
-Alert API
curl -XGET "https://localhost:9200/_plugins/_alerting/monitors/alerts?pretty=true" -k
아래와 같이 발생한 Alert 리스트를 JSON 포맷으로 조회할 수 있습니다.
Alert 이 발생했을 때 관리자에게 통보하는 방식과 통보 메시지 등을 설정하는 기능입니다.
Channel 이라는 설정을 하게 되는데 쉽게 말하면 통보 수단을 의미하는 거고 기본적으로 아래와 같은 통보 수단을 제공합니다.
기존에 자체적인 alert 처리 서비스가 있어서 이 서비스를 활용하고자 Custom webhook 방식을 사용했습니다.
Action > Notification 에서 정의하는 Message 를 JSON 형식으로 우리의 alert 처리 서비스에 전달하는게 목적입니다.
전체적인 Action > Notification 설정은 아래와 같습니다.
- Message
통보 수단을 통해 전달된 메시지 내용을 정의합니다.
Message 에 사용할 수 있도록 제공되는 대략적인 정보 입니다.
- ctx.monitor : Moniter 설정 정보
- ctx.trigger : Trigger 설정 정보
- ctx.newAlerts : 신규 생성 Alert 정보
- ctx.completedAlert : 완료된 Alert 정보
- ctx.dedupedAlerts : 기존 생성된 Alert 중복 생성 정보
ctx 내용 전체를 확인해 보면 활용할 수 있는 내용이 그렇게 많지는 않습니다.
목표로 했던 기능 중에 Alert 서비스에 발생된 Alert 의 실제 쿼리 범위 시간을 구해야 되는 했던 기능이 있었습니다. 아래 두 가지 값이 제공되어 값을 확인해 보니 조건 쿼리가 실행되는 interval 시간으로 확인 되어 실제로 사용하지는 못했습니다.
ctx.periodStart
ctx.periodEnd
대신 ctx.periodEnd 시간에 실제 쿼리 내에 정의된 time range 값을 계산하여 실제 쿼리 범위 시간을 구하는 방식으로 처리 했습니다.
- Perform action
Alert 단위에 대한 Action 처리 방식은 아래와 같은 종류도 설정할 수 있습니다.
- Per execution: 조건을 만족하는 alert 이 여러 개여도 action 은 한번만 처리.
- Per alert: 조건을 만족하는 alert 이 여러 개면 각각마다 action 을 수행함.
우리는 각각의 Alert 마다 action 처리가 필요하기 때문에 Per alert 방식을 사용했고,
Actionable alerts 아래와 같이 설정 했습니다.
- New: 신규 Alert 에 대한 Action 처리를 위해서 반드시 필요한 부분이고
- De-duplicated: 이미 생성된 Alert 에 대해 동일한 조건이 만족되었을 때 Action 을 처리할 것인가를 설정하는 내용입니다. 기존 생성된 Alert 의 상태 정보를 업데이트 시켜 주기 위해서는 이 설정을 추가해줘야 됩니다.
- Completed: 발생된 Alert 의 조건이 만족하지 않게 된 경우 Action 처리 여부를 설정합니다. 기존 발생된 Alert을 자동으로 완료 처리해주려면 이 설정을 추가해줘야 됩니다.
Action 에서 설정된 내용 데로 통보 수단을 통해 충실히 전달된다면, 실제 서비스 로직 에서 제대로 처리해줘야만 됩니다.
- Notication message 처리
Alert 을 처리하는 서비스 로직 에서는 아래 같이 Alerting Notication 으로 message 를 전달 받게 됩니다. 자체 서비스 로직 에서는 이 정보를 분석하여 발생된 Alert 를 관리하는 기능을 구현할 수 있습니다.
어떤 감시설정으로 발생된 Alert 인지를 식별할 수 있는 정보입니다. 서비스 로직에서 감시설정, Alert 을 식별하여 처리하는데 필요한 정보 입니다.
priod_start, period_end : 감시설정의 조건 쿼리가 실행되는 interval 시간 입니다.
만약 쿼리문에 time range 값이 아래처럼 정의 되어 있고 alert 이 발생된 시점에 time range 를 구하려 한다면 위의 시간 값 만으로는 어렵습니다.
Period_start 에 30m을 더하거나 period_end 에서 30m 빼는 방식으로 실제 time range 값을 구할 수 있었습니다.
results[0].aggregations.by_agg.buckets
이 값에서는 검색조건 결과에 해당하는 buckets 결과 값을 구체적으로 조회할 수 있습니다.
New_alerts : 신규 생성 alert
deduped_alerts : 기존 발생된 alert
completed_alerts : 완료된 alert
위와 이 서비스 로직에서 alert 의 상태를 구분하여 처리할 수 있습니다.
이번 글에서는 Alerting Plugin 기능을 큰 카테고리별로 나누어, 주로 OpenSearch Dashboard 를 기반으로 설명했습니다. Alerting Plugin 은 기본적인 API 를 제공하므로, 위에서 다룬 모든 기능은 REST API 를 통해서도 동일하게 활용할 수 있습니다.
따라서 Alerting Plugin 을 탐지 엔진으로 잘 활용한다면, 운영 환경에서 안정적이고 효율적인 탐지 체계를 구축할 수 있습니다.
개발 2그룹에서 SIEM의 개발과 유지보수를 담당하고 있습니다.
