보안~
이 페이지는 로그인 보호, API 키, 감사 로그를 다룹니다. 웹 연결 자체의 암호화는 일반 설정의 HTTPS 강제 항목을 참조하십시오.
비밀번호 요구사항~
비밀번호는 8자 이상이어야 하며 문자·숫자·기호만 사용할 수 있습니다. 흔히 쓰이는 비밀번호(password, qwerty123 등, 크리덴셜 스터핑 공격에 쓰이는 목록에 포함된 값)는 길이 조건을 만족해도 거부됩니다.
AoT는 주기적인 비밀번호 변경을 강제하지 않습니다. 정기적인 강제 변경은 더 이상 권장되는 방식이 아닙니다 — 실제로 다른 비밀번호를 쓰게 만들기보다는 "Password1", "Password2"처럼 예측 가능한 소소한 변형으로 이어지는 경향이 있고, 여기서는 요구하지 않습니다.
계정 잠금~
한 계정에서 로그인 실패가 5회 누적되면, 어느 기기·브라우저에서 시도했는지와 무관하게 그 계정이 10분간 잠깁니다. 카운터는 로그인에 성공하면 초기화됩니다. 이 규칙은 비밀번호 로그인, 키패드 로그인, 아래의 2단계 인증 코드에 동일하게 적용됩니다 — 틀린 인증 코드도 틀린 비밀번호와 같은 방식으로 집계됩니다.
이 값들은 고정값이며 현재 설정 화면에는 노출돼 있지 않습니다.
2단계 인증 (TOTP)~
AoT는 Google Authenticator, Authy, 1Password 같은 앱이 만드는 표준 6자리·30초 코드(RFC 6238 TOTP — 이 앱들이 다른 서비스에서 이미 쓰고 있는 것과 같은 표준)를 이용한 2차 로그인 인증을 지원합니다.
특정 사용자에게 활성화돼 있으면, 로그인 시 비밀번호를 먼저 입력한 뒤 인증 앱의 현재 코드를 추가로 입력해야 합니다 — 둘 중 하나만으로는 로그인할 수 없습니다.
아직 자체 설정 화면은 없습니다
현재 AoT에는 사용자가 직접 이 기능을 켤 수 있는 화면이 없습니다 — 계획은 돼 있으나 아직 구현되지 않았습니다. 그때까지는 관리자가 직접 설정해야 합니다(aot.utils.totp.generate_secret() 로 비밀 값을 생성하고 해당 계정의 totp_secret / totp_enabled = True 를 설정). 한 번 활성화되면 별도 설정 없이 위의 로그인 동작이 바로 적용됩니다.
API 키~
API 키는 브라우저 세션 없이 HTTP API에 대한 요청을 인증합니다. 관리 → 시스템 관리 → 사용자에서 사용자를 편집한 뒤 API 키 생성을 누르면 발급됩니다.
키는 생성되는 그 순간 딱 한 번만 표시됩니다. AoT는 키 자체를 저장하지 않고 단방향 해시만 저장하므로, 설정 화면에서 발급된 키를 다시 보여줄 수 없습니다. 생성 직후 바로 안전한 곳에 복사해 두십시오. 분실했다면 새로 발급하십시오 — 예전 값을 복구할 방법은 없으며, 새로 발급하는 즉시 이전 키는 무효화됩니다.
키는 세 가지 방식으로 제시할 수 있습니다: X-API-KEY 헤더, HTTP Basic 인증, 또는 (폐기 예정 — API.md 참조) api_key 쿼리 파라미터. 키를 재발급하면 이전 키는 즉시 무효화되므로, 재발급 전에 옛 키를 쓰는 스크립트나 연동을 먼저 업데이트하십시오.
감사 로그~
관리 → 감사 로그(시스템 로그와 동일한 "로그 보기" 권한 필요 — 기본 역할 중에서는 관리자·편집자·모니터가 이 권한을 가지며, 손님과 키오스크는 갖지 않습니다. 역할 참조)는 누가·언제· 어디서·무엇을 했고 성공했는지를 훑어보고 걸러 볼 수 있는 기록입니다.
무엇이 기록되는가~
- 로그인 성공·실패·계정 잠금, 로그아웃
- 사용자 생성·수정·삭제
- 그룹 생성·수정·삭제, 그룹 구성원이나 자원 부여의 변경
- 일반 설정 변경
- 장치 제어 — 대시보드에서 사람이 출력을 조작한 것, AI 에이전트가 그를 대신해 조작한 것, 관수 시퀀스가 밸브를 열고 닫은 것. PID/PWM 제어기와 환경 코디네이터의 연속적인 자동 제어는 의도적으로 여기 포함되지 않습니다 — 한 행당 한 동작을 남기는 표에 담기엔 너무 잦기 때문이며, 대신 시계열 측정 데이터의 태그로 추적됩니다. 드라이버 자체의 기동·종료· 삭제도 기록됩니다 — 하드웨어 상태를 직접 바꿀 수 있기 때문입니다.
- API 키 발급·회수, 그리고 폐기 예정인 URL 쿼리스트링 방식 키 인증 사용
- 원격관리 토큰 발급
- 이 감사 로그 자체를 CSV로 내보낸 것, 그리고 소프트웨어 업데이트 요청 (업그레이드 화면에서 직접 누른 것이든, 예약된 자동 업데이트 점검에서 나온 것이든)
작업(Action) 필터에는 자주 쓰는 항목만 나열돼 있습니다. 위의 업데이트 요청처럼 그 목록에 없는 일부 행위도 실제로는 기록되며, 필터를 전체로 두면 볼 수 있습니다.
AI 도구 호출과 그 승인 과정은 이 로그에 포함되지 않습니다 — 별도의 승인 기록으로 남으며, Safety & Approval Model 에서 설명합니다. 이 화면에는 그 결과로 실행된 장치 제어 행위만 AI 주체로 표시되어 남습니다.
표 읽는 법~
| 열 | 의미 |
|---|---|
| Timestamp | 발생 시각. 화면에는 사용자의 로컬 시간대로 표시됩니다(내부 저장은 UTC) |
| Action | 도메인.동사 형태의 행위 이름 — 예: login.failure, output.control |
| Result | success 또는 failure. 거부되거나 실패한 시도도 성공한 것과 마찬가지로 기록됩니다 |
| User | 로그인한 사람이 행위자라면 그 계정명. 장치 제어의 경우 계정 대신 무엇이 그 동작을 일으켰는지가 표시되기도 합니다 — 시퀀스, 드라이버 생명주기 단계(startup/shutdown), 또는(예약된 업데이트 점검이라면) auto-update |
| IP Address | 요청이 들어온 주소. 읽어 올 브라우저 요청 자체가 없었던 경우(AI 에이전트의 명령, 드라이버 생명주기 이벤트)는 비어 있습니다 |
| Target Object | 무엇을 대상으로 했는지 — 종류와, 알 수 있는 경우 이름(출력 이름, 설정 이름 등) |
| Detail | 짧은 자유 서술. 장치 제어의 경우 채널, 요청된 상태, 그리고 판정된 출처(user, ai, sequence, lifecycle, 또는 어떤 경로도 출처를 밝히지 않았다면 unknown — 보인다면 한 번 들여다볼 가치가 있습니다)가 포함됩니다 |
CSV 내보내기에는 화면에는 없는 열이 추가됩니다 — user_id, target_id, 그리고 값의 변화가 의미 있는 행위(현재는 설정 변경)에 한해 채워지는 before/after JSON입니다.
필터링과 내보내기~
Action, User(부분·대소문자 구분 없는 일치), Result로 필터링할 수 있고, 표시할 행 수(Rows, 최대 1000)도 지정할 수 있습니다. CSV 내보내기는 현재 Action/User/Result 필터에 맞는 모든 행을 내려받습니다 — Rows 상한은 적용되지 않으므로, 화면에 보이는 것보다 더 많은 행이 파일에 담길 수 있습니다.
보존 기간~
1년(AUDIT_LOG_RETENTION_DAYS)이 지난 기록은 매일 도는 백그라운드 작업이 자동으로 삭제합니다. 이 기간은 현재 설정 화면에서 바꿀 수 없습니다.
비밀번호, 비밀번호 해시, API 키 자체는 감사 로그에 절대 기록되지 않습니다 — 어떤 행위가 있었는지와 누가 했는지만 기록됩니다.
원격관리(Remote Admin)~
원격관리는 한 AoT 인스턴스가 다른 AoT 인스턴스의 데이터를 표시하게 해주는 기능입니다. /remote/setup으로 직접 접속해야 하며, 현재 메인 메뉴에는 연결돼 있지 않습니다.
원격 호스트를 추가할 때 해당 호스트의 사용자명·비밀번호를 입력받지만, 이는 최초 1회 인증용일 뿐입니다. 실제로 저장되는 것은 그 목적으로 원격 호스트가 발급한 전용 접속 토큰이며, 계정의 비밀번호나 그 해시가 아닙니다. 저장된 토큰이 유출되더라도 그 호스트 하나에 대한 원격관리 접근만 영향을 받고, 계정의 실제 로그인 자격증명은 영향받지 않습니다.
이 최초 1회 비밀번호는 원격의 인증서로 검증되는 연결로만 전송됩니다. 자격증명을 하나도 보내지 않은 상태에서 인증서를 먼저 받아 고정하고, 비밀번호는 그 고정된 인증서로 검증되는 연결로만 나갑니다. 이전 버전은 순서가 반대였습니다 — 비밀번호가 검증되지 않은 연결로 먼저 나가고 인증서는 응답 본문에서 받아 고정했기 때문에, 중간에 있는 누군가가 비밀번호를 그대로 읽고 자기 인증서를 고정시켜 이후 모든 연결을 가로챌 수 있었습니다.
첫 접속의 신뢰는 여전히 사용자 몫입니다 — 처음 본 인증서는 대조할 기준이 없습니다. 그래서 호스트를 추가할 때 고정된 인증서의 SHA-256 지문을 보여줍니다. 연결을 신뢰하기 전에 다른 경로로(원격 장비에서 직접) 지문을 대조하십시오.
이후 인증서가 고정된 것과 달라지면 등록이 중단되고 아무것도 전송되지 않습니다. 원격이 실제로 인증서를 교체한 경우에는 해당 원격 호스트를 삭제한 뒤 다시 추가하십시오 — 삭제 시 옛 고정도 함께 해제됩니다.
업그레이드 후 기존 원격 호스트는 재등록이 필요합니다
이 토큰 방식이 도입되기 전 버전에서 업그레이드하면, 이전에 추가해둔 원격 호스트가 더 이상 연결되지 않습니다. /remote/setup에서 각 호스트를 삭제하고 다시 추가하면 새 토큰으로 연결이 재설정됩니다.