Skip to content
isdnetworks
Go back

기록의 계정으로 사람을 특정할 수 없었다

MySQL 설정 표의 값이 바뀌어 있었다. 누가 바꿨는지 이력을 봤다.

2016-09-18 14:22  admin  device_interval  60 → 10

admin 이고 그 계정은 다섯 명이 같이 쓴다.

Table of contents

Open Table of contents

물어보고 다녔다

다섯 명에게 물었다. 두 명이 기억이 안 난다고 했고 세 명은 아니라고 했다.

access_log 를 봤는데 그것도 계정 기준이라 도움이 안 됐다. IP 기록이 있어서 그것으로 좁혔지만 사무실 안에서 접속한 것이라 결국 못 좁혔다.

기록이 있어도 주체를 못 가리면 없는 것과 비슷하다. 무엇이 바뀌었는지는 알아도 왜 바뀌었는지를 물어볼 대상이 없다.

계정을 나눴다

manager 표에 사람마다 계정을 만들었다.

admin_kim
admin_lee
admin_park
...

admin 은 남기되 접속을 막았다. 그 계정으로 만든 자료의 소유가 걸려 있어서 지울 수는 없었다.

UPDATE manager SET use_yn = 'N' WHERE login_id = 'admin';

지워 버리면 그 계정으로 남은 옛 이력이 어디에도 안 걸린다.

권한도 같이 나눴다

계정만 나누는 김에 role 도 봤다. 다섯 명이 하는 일이 달랐다.

운영 담당    설정 변경, 장치 관리
고객 담당    조회, 문의 답변
개발        전체

전부 같은 role 을 갖고 있을 이유가 없었다. 권한을 나누니 실수도 줄었는데 고객 담당이 설정 화면에 못 들어가니 실수로 바꿀 일이 없다.

이력에 남길 것과 사유

계정만으로 부족한 경우가 있어서 몇 가지를 더 남겼다.

CREATE TABLE config_history (
  history_no  INT NOT NULL AUTO_INCREMENT,
  config_key  VARCHAR(50) NOT NULL,
  old_value   VARCHAR(255) NULL,
  new_value   VARCHAR(255) NULL,
  manager_id  INT NOT NULL,
  ip          VARCHAR(45) NULL,
  user_agent  VARCHAR(255) NULL,
  reg_date    DATETIME NOT NULL,
  PRIMARY KEY (history_no)
);

ipuser_agent 를 같이 남기니 원격에서 접속한 것인지 사무실인지가 갈린다.

설정 변경 화면에는 사유 입력을 넣었다.

장치 수집 주기: 60 → 10
사유: [                    ]  (필수)
2016-09-18 14:22  admin_kim  device_interval  60 → 10
  사유: 현장 요청으로 데이터 수집 주기 단축 (임시, 9/25 복구 예정)

이것이 있으면 왜를 물어볼 필요가 없다. 임시라고 적힌 것은 복구 예정일에 확인하게 했고 입력이 번거로우니 대상을 몇 개로 좁혔다.

검증 — 주체 구분과 알림

crontab 의 배치가 값을 바꾸는 경우도 있었다. 그것도 이력에 남는데 manager_id 가 없다.

ALTER TABLE config_history ADD COLUMN source VARCHAR(20) NOT NULL DEFAULT 'manual';
manual  사람이 화면에서
batch   배치가 자동으로
api     외부 요청으로

사람이 한 것과 시스템이 한 것을 섞으면 조사할 때 헷갈린다.

이전 값이 이력에 있으니 복구 버튼도 넣었다.

2016-09-18 14:22  device_interval  60 → 10   [이 값으로 복구]

누르면 UPDATE 가 돌아 60으로 간다. 그 복구도 이력에 남고 복구가 쉬우면 조사에 시간을 덜 쓴다.

중요한 설정이 바뀌면 알리게 했다.

$critical = ['device_interval', 'alert_threshold', 'retention_days'];

if (in_array($key, $critical)) {
    notify("설정 변경: {$key} {$old}{$new} ({$manager}, {$reason})");
}

바뀐 것을 나중에 발견하는 것보다 낫다. 전부에 알림을 붙이면 시끄러우니 critical 목록을 정했다.

정리


Share this post on:

Previous Post
테스트가 없는 코드를 고칠 때
Next Post
배포 절차를 문서로 만들며