Бірлік 10 / 11

Оқиғаға ден қою және бизнестің үздіксіздігі

Табыстар:

  • AI-ға тән оқиға түрлерін жіктеу және жауап беру циклін жобалау мүмкіндігі
  • Оқиға алдында рөлдерді, өкілеттіктерді және заңды есеп беру міндеттемелерін анықтау мүмкіндігі
  • Бизнестің үздіксіздігімен және кінәсіз постмортеммен тұрақты жақсартуды орнату мүмкіндігі

Сіз оны қаншалықты жақсы қорғасаңыз да, бір күні бірдеңе дұрыс емес болады: кілт ағып кетеді, инъекция жұмыс істейді, провайдер бұзылады немесе өнім тұтынушыға зиян тигізеді. Жетілген мекемені жетілдіретін нәрсе - оқиғалардың жоқтығы емес, оқиға болған кезде дайындық және жылдам болу. Бұл бөлімде біз AI-ға тән оқиғаға әрекет ету жоспарын, рөлдерді, қадамдарды және бизнес үздіксіздігін үйренеміз.

Неліктен AI-де инцидентке жауап беру әртүрлі?

Классикалық қауіпсіздік оқиғасында «жүйені өшіру, оқшаулау» жиі жеткілікті. AI оқиғаларының қосымша өлшемдері бар: оқиға кодта емес, модельдің әрекетінде болуы мүмкін (мысалы, жүйелі қате/бағалаулы шығу); дәлелдеме сұрау/жауап журналдарында; және «болдырмау» кейде мүмкін емес, себебі қате нәтиже шешімге айналды. Сондықтан, AI оқиғасы жоспары классикалық қауіпсіздікті де, мінез-құлықты да қамтуы керек.

Назар аударыңыз: Оқиға болған кезде жоспар жазылмайды, орындалады. Кімнің кімге телефон соғатыны, кімнің «жүйені тоқтатуға» құзіреті бар және байланыс қалай жүзеге асатыны шараға дейін шешілуі керек.

AI оқиғасының түрлері

  • Деректер ағуы: PII немесе құпия деректер сыртқа шықты (шару, журнал немесе шығыс арқылы).
  • Қауіпсіздікті бұзу: ағып кеткен кілт, сәтті енгізу, рұқсатсыз кіру.
  • Зиянды/біржақты нәтиже: Модель жүйелі түрде дұрыс емес, кемсітетін немесе қауіпті жауап берді.
  • Қызметтің үзілуі: Провайдер апатқа ұшырады немесе жылдамдық шегіне жетті; Жүйе жауап бере алмайды.
  • Теріс қолдану: Жүйе ол әзірленбеген зиянды мақсатта пайдаланылған.

Қадамдық: Оқиғаға жауап беру циклі

  1. Анықтау. Бақылау дабылы, пайдаланушының шағымы немесе аудиттің нәтижесі оқиғаны көрсетеді.
  2. Сұрыптау және басымдық беру. Әсері мен таралуына негізделген деңгейлерді беріңіз (мысалы, P1 сыни – P3 төмен).
  3. Құрамында. Спрэдті тоқтатыңыз: кілтті қайтарып алыңыз, мүмкіндікті өшіріңіз, жүйені тек оқуға арналған етіп тартыңыз.
  4. Жою және қалпына келтіру. Түбір себебін түзетіңіз, қауіпсіз күйге оралыңыз.
  5. Хабарлаңыз. Заңды/келісімшарттық хабарлама міндеттемелерін (мысалы, KVKK 72 сағат) және зардап шеккендерді уақтылы хабарлаңыз.
  6. Оқиғадан кейінгі тексеру (өлгеннен кейінгі). Кінәлі болмай, негізгі себебін құжаттаңыз және тұрақты түзету.

Рөлдер мен жауапкершіліктер

Оқиға кезінде кімнің не істейтіні анық болуы керек: оқиға командирі (шешім қабылдайтын жалғыз адам), техникалық әрекет (жүйені тоқтату/жөндеу), байланыс (тұтынушы/басқару/реттеу), заңдылық/сәйкестік (хабарлау міндеттемесі). Шағын командаларда бір адам бірнеше рөлді атқара алады, бірақ рөлдер жазылуы керек.

Көшірілетін төрт үлгі

Оқиғаның жіктелуі:

Келесі оқиғаны жіктеңіз: {{ event_description }}Анықтаңыз:- Түрі: деректердің ағуы / қауіпсіздіктің бұзылуы / зиянды нәтиже / үзіліс / теріс пайдалану- Әсері: қанша адам/жазба, қандай деректер класы, ақша/сәйкестік салдары?- Таралу: тоқтатылды немесе жалғасуда ма?- Басымдық: P1 / P2 / P3 дереу не істеу керек?

Бірінші жауап (контейнер) бақылау тізімі:

Оқиға расталған алғашқы 30 минутта:- [ ] Зақымдалған мүмкіндікті/құралды өшіріңіз немесе оны тек оқуға арналған етіп орнатыңыз- [ ] Күдікті кілттерді/сеанстарды болдырмаңыз- [ ] Дәлелдерді сақтаңыз (тиісті журналдарды қатыру, trace_id жазу)- [ ] Оқиға командиріне және қажетті рөлдерге хабарлау- [ ] Уақытша сақтық көшірме ағынының қауіпсіз режимін қолдану /

Хабарландыру жобасының нұсқауы:

Келесі оқиға үшін ішкі хабарлама жобасын жазыңыз: {{ insident_summary }}Көрту керек: не болғаны (техникалық емес тілде), ол қашан байқалды, қандай деректер/кім әсер етті, осы уақытқа дейін не істелді, келесі қадамдар, қосымша ақпаратты кімнен алуға болады. Болжамдарды немесе айыптауларды қоспаңыз.

Өлгеннен кейінгі қаңқа:

Оқиғадан кейінгі шолу (кінә жоқ):- Уақыт шкаласы: анықтау -> бақылау -> қалпына келтіру (минут сайын)- Түбірлік себеп: техника + процестің өлшемі- Не жақсы болды / не нашар болды- Тұрақты түзетулер (кім, қашан)- Бұл оқиғаны тезірек ұстау үшін бақылау/бақылау

Әлсіз шақыру / Күшті шақыру

нашар көзқарас

Күшті көзқарас

Іс-шарада жоспарсыз экспромт

Алдын ала жазылған жоспар, рөлдер мен өкілеттіктер

Алдымен «кім кінәлі» деп айт.

Алдымен оқшаулау, содан кейін кінәсіз

Кешіктіру/өткізу хабарламасы

Заңды мерзім ішінде хабарландыру (мысалы, 72 сағат)

Дәл сол оқиғаның қайталануын күту

Өлімнен кейін тұрақты бақылауды алу

Үш шағын корпус

1-жағдай - 72 сағат ережесінде ұсталды. Бір компанияның қызметкері қате конфигурацияға байланысты журналда 1200 тұтынушы жазбасының ашық қалғанын байқады. Жазбаша жоспардың арқасында оқиға командирі анық болды; Команда кіруді 40 минутта жауып, заң KVKK хабарламасын 72 сағат ішінде жасады. Уақтылы хабарлау қылмыстық тәуекелді және беделге нұқсан келтіруді айтарлықтай азайтты.

2-жағдай — Тек оқуға арналған қауіпсіз режим үзілістерді өңдеді. Негізгі модель провайдері 3 сағатқа шықты. Фирманың үздіксіз жұмыс жоспары сақтық көшірме провайдеріне және «қауіпсіз режимге» ауысуды қамтиды (тек маңызды функциялар). Пайдаланушылар толық функционалдығын жоғалтқанымен, жүйе аман қалды; маңызды операциялар тоқтаған жоқ.

3-жағдай – өлімнен кейінгі қайталанудың алдын алды. Сәтті жанама инъекция басқа пайдаланушының деректерін көмекшіге жіберді. Өлімнен кейінгі кінәні жоққа шығару негізгі себеп <деректер> оқшаулаудың жоқтығын көрсетті. Тұрақты түзету қосылды (оқшаулау + шығыс сканерлеу + регрессия сынағы); Дәл сол кластағы шабуыл қайтадан сәтті болмады.

Кеңес: Өлімнен кейінгі операцияны кінәсіз жүргізіңіз. Мақсат адам табу емес, жүйені сол оқиғаның қайталануына жол бермейтіндей етіп күшейту. Кінәлау мәдениеті адамдарды жасыруға мәжбүр етеді және бұл ең қауіпті.

Жалпы қателер

  • Оқиға алдында жазбаша жоспар мен рөлді бөлуді дайындамау.
  • Бақылауды қолға алмас бұрын дауға/кінәға түсу.
  • Жетіспейтін заңдық хабарландыру міндеттемелері (KVKK/GDPR мерзімдері).
  • Дәлелдемелерді (журналдарды) сақтамай жүйені қалпына келтіру.
  • Бизнес үздіксіздігі үшін сақтық көшірме провайдерін/қауіпсіз режимді қарастырмау.
  • Өлімнен кейінгі операция жасамау және сол оқиғаның қайталануы үшін орын қалдыру.

Қысқаша айтқанда

  • Жетілу – оқиғалардың жоқтығы емес; Бұл жағдай орын алған кезде дайындалу және жылдам болу дегенді білдіреді.
  • AI оқиғалары кодтан гөрі үлгілік әрекетте болуы мүмкін; Дәлелдеу жедел/жауап журналдарында және кері қайтару әрқашан мүмкін емес.
  • Жауап беру циклі: анықтау, жіктеу, қамту, қалпына келтіру, хабарлау, өлгеннен кейін.
  • Рөлдер мен өкілеттіктер (оқиға командирі, техникалық, байланыс, құқықтық) оқиға алдында жазбаша түрде болуы керек.
  • Сақтық көшірме провайдері/бизнес үздіксіздігі үшін қауіпсіз режим; Өлімнен кейінгі кінәсіз және тұрақты түзету оқиғаның салдары үшін өте маңызды.

Қолданбалы тапсырма

Жеке AI жүйеңіз үшін оқиғаға жауап беру жоспарының жобасын жазыңыз: оқиғаның ең ықтимал үш түрін тізімдеңіз, 30 минуттық бастапқы бақылау тізімін және әрқайсысы үшін рөлдерді анықтаңыз. Содан кейін үстел үстіндегі жаттығуды орындаңыз: «кілт ағып кетті» сценарийін кезең-кезеңмен орындаңыз және жоспарыңыздағы жетіспейтін/анық емес нүктелерді көрсетіңіз және түзетіңіз.

бақылау парағы

  • [ ] Жазбаша оқиғаға жауап беру жоспары және рөлді бөлу бар.
  • [ ] «Жүйені тоқтатуға» кімнің құқығы бар екені анық.
  • [ ] Алғашқы 30 минуттық шектеуді бақылау тізімі дайын.
  • [ ] Заңды хабарлау мерзімдері мен жауапты тұлға анықталды.
  • [ ] Сақтық көшірме провайдері/қауіпсіз режим бизнес үздіксіздігі үшін жоспарланған.
  • [ ] Әрбір оқиға үшін кінәсіз өлімнен кейінгі және тұрақты түзету орындалады.