Ішкі жүйелерге арналған OWASP бойынша қауіпсіз әзірлеу: практикалар

Ішкі жүйелерге OWASP не үшін қажет практикалық жағынан

Ішкі жүйелер көбіне «әдепкі бойынша қауіпсіз» деп есептеледі: тек кеңседен қолжетімді, барлық қолданушылар таныс, деректер «жария емес». Шындығында осындай жүйелер тексерілмегендіктен және онда компромисстер жиналатындықтан оңай нысанаға айналады.

Оларға шабуылдар тек «сырттан» болмайды. Сценарийлер әдетте қарапайым: фишинг есептік жазбаны ұрлап алады, мердігер жоба аяқталғаннан кейін қолжеткізуді қалдырады, сервисті конфигурация қателігі себебінен интернетке ашады, кейде зиянды әрекетті инсайдер жасайды. Автоматтандыру да жиі мәселе болады: скрипттер, интеграциялар мен боттар көптеген сұраулар жібереді және «қолмен» тексерулерді айналып өтуі мүмкін.

Ішкі жүйелердегі салдарлар «киберкатастрофа» сияқты көрінбеуі мүмкін, бірақ шығындары үлкен: персоналдық немесе коммерциялық ақпаратың ағуы, өтініштердегі реквизиттердің өзгеруі, анықтамалықтар мен рольдердің бұрмалануы (нәтижесінде қолжетімділік тарап кетуі), деректерді жоюдан, шифрлаудан немесе шамадан тыс жүктемеден сервис тоқтау.

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

Шекараны түсіну маңызды: ішкі командада OWASP бойынша қауіпсіз әзірлеу — «мінсіз қауіпсіздікті» жасау емес, күнделікті жұмысқа оңай ендірілетін тұрақты дағдылар жиыны. Қайда құпия сақтау, енгізуді қалай тексеру, «кіру» мен «рұқсат» арасын қалай бөлу, тәуекелге бағытталған ревью қалай жүргізу — осылар туралы. Тіпті осындай минимум ішкі жүйелердегі типтік әлсіздіктердің көп бөлігін жауып қояды.

Қысқа қатер моделі: нені қорғаймыз және кімнен

OWASP-практикалар «түрлі үшін» болмасын десеңіз, қысқа қатер моделінен бастаңыз. Ол 30–60 минутты алады және нақты нені қорғайтыныңызды, қандай шабуылдар шындыққа жақын екенін айқындайды.

Басында жүйеден өтетін деректер мен олардың қайда сақталатынын тізіп шығыңыз. Әдетте бірнеше категория жеткілікті: қызметкерлер мен клиенттердің жеке деректері, қаржы (шоттар, лимиттер, өтініштер, бағалар), қызметтік құжаттар (шарттар, спецификациялар), тіркелімдер мен құқықтар (рольдер, токендер, кілттер, журналдар), техникалық деректер (логтар, дамптар, экспорттар).

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

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

Соңында «ең қауіпті» сценарийді таңдап, басымдық беріңіз. Оған мыналар көмектеседі:

• Ең үлкен зиянды не тигізеді: ағу, подмена, жұмыс тоқтауы.
• Қай кіріс нүктесі ең қолжетімді және нашар бақыланады.
• Қай жерде салдарлар жасырын болады (қате ұзақ байқалмайды).
• Қай нәрсені массалайтын деңгейде қайталау мүмкін (бір батырма немесе скрипт арқылы).

Мысал: ішкі құрал-жабдық есептеу жүйесіне списание үшін API қосылды. Ең қауіпті сценарий — идентификаторды ауыстыру арқылы бөтен позицияларды списание жасау. Басымдықтар айқын: операцияға қатты құқық тексеру, әрекеттерді аудиттеу және массалық өзгерістерге шектеу қою.

Құпияларды сақтау: сақтауға оңай ережелер

Ішкі жүйедегі құпиялар — тек админ парольдері емес. Ағулар көбіне «уақытша» токендер мен тест кілттерінен басталады, олар кейін кодта қалады. Одан бастау үшін не құпия екенін нақты тізімдеп алыңыз.

Көбінесе бұл: парольдер мен PIN-кодтар, сессия токендері, JWT және refresh токендері, API кілттері мен бұлт кілттері, сертификаттар мен приватті кілттер, дерекқор мен кезектерге қосылу жолдары.

Ереже көп уақыт үнемдейді: құпиялар кодта, репозиторийде, тикеттерде, чаттарда және құжаттамада өмір сүрмеу керек. Тіпті жабық корпоративті Git-та да бұл көшірмеленеді, форк жасалады, бэкаптарға түседі және мердігерлерге жетеді.

Үлкен қайта құрылыстан қашып, практикалық минимум:

1. Құпияларды репозиторийден тыс сақтаңыз: орта айнымалылары немесе коммитталмайтын бөлек конфигтер.

2. Қолжетімділікті бөліңіз: әзірлеуші, CI және прод үшін әрқайсысының өз кілті болсын. Тест токені продты ашпасын.

3. Минималды құқық принципін қолданыңыз: кілт тек қажетті сервис пен операцияға рұқсат берсін.

Ротация мен отзыва процедурасы түсінікті болуы керек. «Мәңгілік» кілттер әдетте ешқашан өзгертілмейді. Мерзім орнатыңыз (мысалы, 60–90 күн) және қызметкер жұмыстан шыққанда, мердігер ауыстырылғанда немесе ағу күдікті болғанда кілттерді дереу өзгертіңіз.

Ағу болса, жоспарыңыз бойынша әрекет етіңіз: кілтті отзыва жасап, жаңасын шығарыңыз, ағу орнын табыңыз (коммит, лог, чат), осы кілтпен орындалған белсенділікті тексеріңіз, барлық қолдану жерлерін жаңартыңыз және қайталанбауы үшін бақылау енгізіңіз.

Арнайы қауіпті орын — логтар, дамптар және қатенің есептері. Authorization тақырыптары, cookies, қосылу жолдары мен password сияқты өрістерді логтамаңыз. Мәндерді маскалаңыз және қателік мәтінінде құпияның кездейсоқ болмауы үшін қауіпсіз логтау шаблондарын қолданыңыз.

Енгізуді тексеру және қауіпсіз шығару: базалық стандарт

Ішкі жүйелер көбіне «компания желісінде тұрса қауіпсіз» деп есептейтінімен, енгізуді өңдеудегі бір қате тез уязвимостьке айналады, тіпті пайдаланушы «өз» болса да. OWASP бойынша қауіпсіз әзірлеудің негізгі стандарты қарапайым: тек күтілетін нәрсені қабылдаңыз және тек қауіпсіз көрсетілетін нәрсені шығарыңыз.

Allowlist (рұқсат етілгендер тізімі) принципі «жаманды тыйыңыз» тәсілінен тиімдірек. «Қайырымсыз символдарды» тыймай, нақты ережелер қойыңыз: тип, ұзындық, формат, мән диапазоны. Ережеден өтпеген бәрін кері қайтарыңыз.

Жүйенің шегінде деректерді тексеріңіз: URL параметрлері, тақырыптар, JSON денесі, файлдар, кезектер мен интеграциялардан келген мәндер. Әр кіріс — сенімсіз, тіпті егер оны басқа сіздің сервисіңіз жіберсе де.

Тексеру алдында нормализация қажет. Жолдарды бір қалыпқа келтіріңіз (аралықтарды қиып алу, бір кодировка), даталарды бір форматқа айналдырыңыз, телефондарды бір маскаға келтіріңіз. Әйтпесе валидация басқа, ал сақтау мен өңдеу басқа күйде болады.

Типтік шабуылдар тәртіппен жабылады. Инъекциялар (SQL/NoSQL) параметрленген сұраулар мен динамикалық жолдардан құралатын сұрауларды тыйу арқылы жойылады. XSS ішкі админкада да оңай пайда болады, егер қолданушы өрістерін экранизацияламасаңыз. Командалық инъекциялар енгізуді shell-ге тікелей жібергенде болады.

Қателерді бейтарап көрсетіңіз: қолданушыға — қарапайым хабар және код, толық деректер (стек, SQL, конфигтер) — тек логта.

Жаңа эндпоинт үшін қысқа тексеру (мысалы, сервис-десктегі өтініш жасау):

• Контрактті сипаттаңыз: міндетті өрістер, типтер, ұзындық, рұқсат етілген мәндер.
• Нормализацияны валидациядан бұрын жасаңыз (аралықтар, регистр, дата форматтары).
• Қосымша және белгісіз өрістерді қабылдамай тастаңыз.
• Қауіпсіз шақыруларды қолданыңыз: параметрленген сұраулар, shell-ді қолданбаңыз.
• Бейтарап қателер қайтарыңыз, толық мәліметтер логта қалсын.

API құқықтары: «кіру» мен «рұқсат» айырмашылығын шатастырмау

Ішкі жүйелердегі жиі қате: адам жүйеге кірді, демек оған көп нәрсе рұқсат. Бұл аутентификация мен авторизацияны араластыру. Аутентификация «сен кімсің?» деп жауап берсе, авторизация — «сен не істей аласың?» деп жауап береді. OWASP бойынша бұл екі нәрсені әрқашан бөлу керек, тіпті жүйе «тек өзге қызметкерлерге» арналған болса да.

Мысал: қойма қызметкері өз аккаунтымен кірсе, бұл оның қаржылық есептерді шығарып немесе басқа пайдаланушылардың құқықтарын өзгерте алатынын білдірмейді. Егер авторизация тек интерфейстегі батырмалардың көрінуіне негізделсе, API-ға тікелей сұрау жіберіп, рұқсатты айналып өту оңай.

Пайдалы ереже — «кем дегенде қажетті құқықтар». Рольдер анық және тар болсын: «қолданушы» мен «админ» сияқты жалпылама емес, нақты тапсырмаларға арналған рольдер. Сервис аккаунттары да бөлек болсын: интеграцияға бөлек аккаунт, бөлек кілттер, жеке құқықтар, «барлығына арналған супер-токен» болмауы тиіс.

Артық сақтықпен қарау қажет жерлер: админ функциялары, массалық операциялар (массалық жою, статус өзгерту), экспорттар, есептер, персоналдық деректермен операциялар. Оларды жиі өткізіп жібереді, себебі «оны тек админдер пайдаланады» деген ой бар.

Тексеру әр API әдісінде болуы керек: оқу, өзгерту, жою, экспорт. Рольге тек ярлык ретінде қараудың орнына, нақты объектіге қатысты әрекетке рұқсатты тексергеніңіз жақсы (мысалы, «өзіне тиесілі бөлімнің өтінішін өңдей алады»).

Оны қағазда қалдырмау үшін әр роль үшін қолжетімділік тесттерін қосыңыз:

• Позитив сценарий: роль X әрекет Y орындауға құқылы.
• Негатив сценарий: роль X әрекет Z орындай алмайды.
• Басқа бөлімдерге тиесili объектілер: бөтен жазбаларды оқуға немесе өзгертуге болмайды.
• Экспорттар мен есептер: жеке рұқсатпен, батырма арқылы мұрагерлік құқықтар болмауы тиіс.
• Сервис аккаунты: шектеулі құқықтар және қосымша эндпоинттерге тыйым.

Қатты тоқтатпай команданың жұмысына практика енгізу

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

Жұмыс тәсілі әдетте мынадай:

• Минималды стандартты бекітіңіз: құпияларды қайда және қалай сақтайсыз, не енгізу жарамды саналады, API құқықтарын қалай тексересіз, не логталады және не логталмайды.
• Тапсырма сипаттамасына «релизге дайын» қысқа чек-лист қосыңыз. Ол 30–60 секундқа сай болу керек, әйтпесе оқылмай қалады.
• Жинаққа (CI) негізгі тексерістер қосыңыз: линтерлер, типтік қателіктерді іздеу, тәуелділіктердің қауіпсіздігін қарау. Бұл қайталанатын мәселелерді ревьюға дейін ұстайтын «қақпа» болу керек.
• Командада қауіпсіздік талаптарының иесін анықтаңыз. Бұл бөлек лауазым емес, стандартты сақтауды бақылап отыратын адам.
• Прогресті өлшеуді бастаңыз: релизге дейін қанша мәселе табылды, кейін қанша табылды және түзетуге кеткен орташа уақыт.

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

Егер түзету уақыты қысқарса және «релизден кейін» табылатын қателер азайса, дұрыс жолдасыз.

Қауіпке бағытталған код-ревью: неге назар аудару керек

Қауіпсіздік бойынша код-ревью жылына бір рет жасалатын аудитқа айналмауы тиіс. Күнделікті практикада бұл OWASP қағидаларын сақтау үшін ең арзан құралдардың бірі: өзгерістер кішкентай болғанда оларды түзету оңай.

Әр PR-да не тексеру керек

Қайталап жасалатын қысқа тексерулер жиынтығынан бастаңыз. Олар әдетке айналып, ревьюны баяулатпайды:

• Валидация және түрлендіруler: енгізу қай жерде тексеріледі, ұзындық пен формат шектелген бе, ішкі мәліметтерге сенім бар ма.
• Құқықтар: аутентификация мен авторизация бөлінген бе, рольдер немесе нақты объектіге арналған рұқсаттар тексеріледі ме.
• Қателер мен логтар: жауапта немесе логтарда мәлімет ағуы (токендер, жеке деректер) жоқ па, қателік кодтары дұрыс па.
• Сыртқы сервистер: таймауттер, қайта шақырулар, «адалмау» жағдайына қарсы қорғаныс және сервистің қолжетімсіздігі кезінде анық мінез-құлық бар ма.
• Әдепкі параметрлер: шектеулер дереу қосылған ба, «кейін қосамыз» жоқ па.

«Қызыл туларды» бөлек анықтау пайдалы. Олар бастапқыда ыңғайлы қысқартулар сияқты көрінгенімен кейін бақылауды айналып өтетін жолға айналады:

• if (isAdmin || debug) сияқты шарттар немесе сұрау параметрімен қосылатын жасырын тармақтар.
• Құқық тек UI-да тексеріледі, серверлік тексеріс жоқ.
• Қауіпсіз емес әдепкі мәндер (мысалы, «барлық аутентификацияланғандар» орнына нақты рөлдер).
• Бар сұрауды түгел логтау, оның ішінде тақырыптар мен токендер.

Ревью тез болсын десеңіз, PR-ды кіші ұстаңыз және сипаттама шаблонын қолданыңыз: не өзгерді, қандай құқықтар затты, сыртқы сервис қателессе не болады. Егер тартысты мәселе болса, қысқа түрде тәуекел мен түзету жоспарын мерзімімен жазып қойыңыз. Мысалы: «Жаңа эндпоинт сыртқы сервиске таймаутсыз жүгінеді; тәуекел — воркердің тоғыруы; түзету: 2–3 секундтық таймаут және анық жауап қайтару».

Ішкі жүйелерді осал ететін жиі қателіктер

Ішкі жүйелердің басты тұзақы — «біз VPN-дамыз, сондықтан жеңілдетуге болады» деген сенім. Шындықта инциденттер көбінесе іштен болады: жалпы есептік жазбалар, мердігерлерге берілген қолжетімдер, фишинг, конфигурация қателері. Сондықтан OWASP ішкі контур үшін әсіресе пайдалы.

Кең тараған қателіктер:

• Әртүрлі ортада әртүрлі ережелер: dev пен test-та «қалай болса солай» деп, содан кейін сол параметрлер prod-қа түсіп кетеді.
• Dev/test/prod-та бірдей парольдер, токендер мен кілттер. Тесттен ағатын бір құпия нағыз жүйеге қолжеткізуді ашады.
• Құқықтарды тек фронтендте немесе бір қызметте тексеру. API-ға тікелей шақыру немесе басқа сервис арқылы айналма жол арқылы тосқауыл оңай бұзылады.
• admin/superuser тәрізді тым кең рольдер. Бастапқыда ыңғайлы, бірақ кейін кім не керектігін түсіну қиынға соғады.
• Логтарда жеке деректер, токендер, құжат нөмірлері және сұраулардың егжей-тегжейі бар. Логтар жиі дерекқордан кеңірек қолжетімді және ұзақ сақталады.

Жай сценарий: қызметкерге сөзсіз бір рет справочникты өзгерту үшін admin рөлі берілді. Бір айдан кейін сол аккаунт есептерді шығару үшін пайдаланады, әрі қарай пароль чатта пайда болады. Нәтиже — барлыққа бірдей толық қолжетімділік, бастапқыда қажет болған бір ғана әрекет үшін.

Тәуекелді тез төмендету үшін бірнеше қадам көмектеседі: құпияларды орталар бойынша бөлу, әр эндпоинтте серверлік құқық тексерісін енгізу, «admin»-ды нақты рұқсаттар жиынымен ауыстыру және логтарда токендер мен сезімтал деректердің болмауын ережелеу.

Релиз алдындағы қысқа чек-лист

Ішкі сервисті жарияламас бұрын қысқа үзіліс жасап, бірдей тексерулерді өтіңіз. Бұл тестті алмастырмайды, бірақ типтік қателерді жиі ұстайды және OWASP қағидаларын әдетке айналдыруға көмектеседі.

Төмендегі тармақтарды тексеріп, нәтижесін релиз тапсырмасында белгілеңіз:

• Құпиялар: репозиторияда парольдер, токендер және кілттер жоқ (мысалы, конфиг мысалдарында да). Қолжетімділік минимумға берілген, ең маңызды кілттерге ротация қарастырылған.
• Енгізу және шығару: негізгі өрістерге allowlist-валидация бар (формат, ұзындық, диапазон). API мен UI-да бірдей ережелер қолданылады, қате хабарлары ішкі егжей-тегжейді көрсетпейді.
• API құқықтары: әр эндпоинтте тек «кірді» тексерумен шектелмей, нақты құқықтар тексеріледі. Рөлсіз рұқсат жоқ екенін растайтын негатив тесттер бар.
• Логтар мен қателер: логтарда құпиялар мен жеке деректер жоқ, тіпті қателік кезінде де. Қате кодтары түсінікті, түзетуге арналған деректер ішкі логта қалады.
• Тәуелділіктер: жаңартулар жоспарланған, критикалық осалдықтар кейінге қалдырылмайды. Егер кітапхананы бірден жаңарту мүмкін болмаса, уақытша шара (настройка, функцияны шектеу, компенсаторлық бақылау) бар.

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

Тәжірибеден мысал: ішкі жүйеде жаңа эндпоинт

Ішкі кадрлар қызметінің командасы «қызметкерлерді экспорттау» эндпоинтін қосты. Идея қарапайым: бөлім басшылары CSV-ға адамдар тізімін шығарып, тарифтер мен кестелерді тексергісі келеді.

Қауіптер де қарапайым, бірақ жағымсыз: жеке деректердің ағуы (толық аты-жөні, ИИН, байланыс), рөлдің дұрыс еместігі (кіру — бәрі демек емес), іздеу фильтрлері (department, name, dateFrom) инъекция немесе шектеулерді айналып өту нүктесіне айналуы мүмкін.

Команда OWASP қауіпсіз әзірлеу шаблонын жеңілдетіп қолданады:

• Рольдер мен құқықтарды анықтайды: HR бәрін көреді, бөлім басшысы — тек өз бөлімін, бухгалтерия — тек қажет өрістер.
• API деңгейінде әр сұрауға рұқсат тексеріледі, «бір рет кіргенде» емес.
• Енгізуді allowlist бойынша валидациялайды: рұқсат етілген фильтр өрістері, форматтар мен даталардың диапазондары.
• Лимиттер қосады: максималды экспорт көлемі, пагинация, сұрау жиілігін шектеу.
• Экспортты қауіпсіз құрастырады: фиксирленген бағандар жиыны, мәндерді экранизациялау, дұрыс тақырыптар, «сырық SQL-ды фильтрге жібермеу».

Ревьюда тек кодқа ғана емес, логтарға да қарайды: логтарда жеке деректер мен құпиялар жоқ па, қателер дерекқор құрылымын ашып бермей ме, әр роль үшін негатив тесттер бар ма. Егер файлға экспорт жасалса, файл аты пайдаланушы енгізуінен құрастырылмайтыны және уақытша файлдардың жойылатыны тексеріледі.

Егер қателік немесе оқиға орын алса (мысалы, бөлім басшысы барлық қызметкерлерді экспорттай алды), команда релиз чек-листіне қосымша тармақ енгізеді: мәліметтердің көріну аясын (scoping) тексеру және API тек рұқсатталған таңдаманы қайтаратынын растайтын міндетті тест.

Келесі қадамдар: практикаларды бекіту және үдерісті жақсарту

OWASP практикаларын бір жолғы бастама етіп қалдырмау үшін келесі екі аптаға 2–3 жақсартуды таңдаңыз және спринт жоспарына кәдімгі тапсырма ретінде қосыңыз. Әр пункттің иесі мен дайын болу критерийі анықталғаны жақсы белгі.

Жылдам әсер беретін жинақ:

• Құпияларды біртұтас хранилищеге көшіру және оларды код пен конфигурацияға тықпауды талап ету.
• Барлық жаңа эндпоинттер үшін енгізуді тексеру стандарты қосу.
• Әр API-әдісте құқықтарды тексеруді қосу (кейіннен емес).
• Ревьюде минимум чек: құпиялар, енгізу, құқықтар, логтау.

Содан кейін 45–60 минуттық қысқа воркшоп пайдалы болады. Теория емес, нақты ережелер: кілттер қайда, қандай өрістер валидацияланады, рольдер мен рұқсаттарды қалай формулировкалау керек, қандай логтар қабылданады. Воркшоптан кейін ережелерді бір бетке жазып, жаңа өзгерістерге міндетті етуді келісіңіз.

Қосымша екі қысқа регламент дайындаңыз, стресс сәтінде жеңіл қолдану үшін:

• Кілт ағып кеткен жағдайда: кім отзыва жасайды, қай жерде өзгертеміз, іздер қалай тексеріледі, кімге хабарлау қажет.
• Осалдық табылса: қалай түзетеміз, тәуекелді қалай бағалаймыз, патчты қалай шығарамыз және постмортем қалай өткіземіз.

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

Егер инфрақұрылым мен енгізуді қатар жасайтын болса, GSE.kz жүйелік интегратор ретінде көмек көрсете алады: серверлер мен жұмыс станцияларын таңдау мен орналастыру, орналастыру мен қолдауды ұйымдастыру және даму мен прод ортасы үшін негізгі қауіпсіздік шараларын енгізу.