Моніторинг безпеки ERP Oracle E-Business Suite, Різне, Security & Hack, статті

Незважаючи на постійний розвиток інформаційних технологій, практика забезпечення інформаційної безпеки в російських компаніях насичена прикладами інцидентів в цій галузі. Більш того, число інцидентів неухильно зростає і починає викликати певне занепокоєння у начальників служб автоматизації (CIO) і служб інформаційної безпеки (CISO), відповідальних за організацію інформаційної безпеки ERP-систем у вітчизняних компаніях. Давайте подивимося, які можливості існують для моніторингу безпеки ERP Oracle E-Business Suite.


Наведемо класичний варіант побудови ERP Oracle E-Business Suite за схемою “база даних – сервер додатків -” тонкий “клієнт”. Три основних компоненти цієї системи з’єднані між собою за допомогою мережі передачі даних на основі TCP / IP (рис. 1). В цьому випадку браузер або будь-яка інша програма, що виконує роль “тонкого” клієнта, візуалізує так звані марковані дані (мови маркування: HTML або XML) для користувачів ERP Oracle E-Business Suite. Введені користувачем запити і команди передаються за допомогою протоколу HTTP через мережу передачі даних сервера додатків. Програми ERP Oracle E-Business Suite виконуються як деякі обчислювальні процеси на сервері додатків і при необхідності здійснюють взаємодію з сервером баз даних (в загальному випадку – розподіленим). При цьому процес обміну даними між додатками і БД ERP Oracle E-Business Suite зачіпає компоненти доступу до реляційної базі даних мови високого рівня, протокол прикладного рівня SQL * Net і стек протоколів TCP / IP. Так як СУБД ERP Oracle E-Business Suite побудована за принципом роздільного, введемо в схему (рис. 1) кластер паралельно функціонуючих серверів баз даних, пов’язаних між собою по протоколу SQL * Net.


Аналіз представленої схеми обробки даних ERP Oracle E-Business Suite (рис. 1) дозволяє виділити сліду-ющие компоненти, відповідальні за перетворення, зберігання та передачу даних:


• програму-браузер, що виконує візуалізацію маркованих даних (перетворення “графічне представлення – HTML / XML-документ”);


• підсистему передачі та кешування маркованих даних;


• прикладну програму на сервері додатків;


• підсистему передачі даних в реляційному поданні;


• підсистему фізичного зберігання даних в рамках СУБД.


Отже, для моніторингу безпеки ERP Oracle E-Business Suite необхідно побудувати деякі контрольні точки або інваріанти обробки даних, а також створити адекватні методи контролю цих інварінтов для наступних процесів:


• візуалізації маркованих даних та інтерфейсу з користувачем;


• протоколу прикладного рівня HTTP;


• протоколу прикладного рівня SQL * Net;


• стека протоколів транспортного, мережевого і канального рівнів TCP / IP;


• прикладної програми (логіки програми);


• підсистеми фізичного представлення реляційних даних в СУБД.


Давайте розглянемо перераховані процеси обробки даних ERP Oracle E-Business Suite детальніше.


     Візуалізація маркованих даних


Керуючий граф програми “тонкого” клієнта представлений на рис. 2. Тут вхідним параметром процесу є строкова величина StartURI – унікальний ідентифікатор ресурсу (URI – unique resource identifier), ініціалізувалися сеанс роботи з користувачем ERP Oracle E-Business Suite. Цей параметр може бути однозначно визначено на етапі розробки ERP-системи, якщо процес ідентифікації і аутентифікації користувача реалізований засобами самого додатка, або величину StartURI повинен надати зовнішній процес ідентифікації в системі.


У загальному випадку розгалуження, пов’язане з можливістю відображення копії документа, що знаходиться в кеші браузера, може залежати від наступних чинників:


• логіки роботи з кешовані документами;


• позначки часу кешированний копії;


• наявності в ідентифікаторі ресурсу змінної складової (запиту) і т. п.


Після завантаження з сервера копії документа і його параметрів заносяться в кеш для подальшого використання. При цьому алгоритм візуалізації перетворює так звані марковані дані, отримані від сервера додатків, у внутрішню структуру даних браузера, а потім у графічне представлення на пристрої виводу. Після візуалізації документа браузер переходить в цикл очікування і очікує дій користувача. Розрізняють три варіанти дій користувача:


• вихід з програми;


• редагування змінних величин;


• виклик команди до сервера додатків.


При спробі користувача виконати операцію редагування браузері мають перевірити доступність величини на зміну. При запиті команди для сервера додатків браузері мають:


• визначити неизменяемую частина унікального ідентифікатора;


• визначити набір величин, пов’язаних з даним запитом (командою);


• сформувати список пар “назва величини – значення величини”;


• сформувати конкатенації повний ідентифікатор ресурсу URI.


Внутрішню структуру представлення даних в програмі-браузері можна представити у вигляді двох наборів даних:


• записів про команди, доступних користувачеві при роботі з даним документом (в мові HTML з командами пов’язані елементи управління “посилання” і “форма”):


• URL1, URL2, … , URLCC – постійними складовими ідентифікаторів ресурсів, пов’язаних з даною командою (тип даних – рядковий);


• CM1, CM2, … , CMCC – інформації про правила відображення керуючого елемента, пов’язаного з даною командою (тип даних – структура);


• записів про величини (в мові HTML з постійними величинами пов’язаний елемент управління “текст”, зі змінними – елемент управління “input”):

• VN1, VN2, … , VNVС – імен величин (тип даних – рядковий);


• VV1, VV2, … , VVVС – значень величин (тип даних – рядковий, або в залежності від величини – рядковий, цілочисельний, речовинний, логічний);


• VW1, VW2, … VWVС – логічних ознак можливості редагування значення величини в програмі-браузері (тип даних – логічний);


• VR1, VR2, … , VRVС – порядкових номерів команди, з якою пов’язана дана величина (в мовах маркованого подання даних HTML та XML дотримується строга ієрархічна структура елементів управління і візуалізації, внаслідок цього кожна конкретна величина може бути пов’язана тільки з однією командою (тип даних – цілочисельний, діапазон допустимих значень – [1 .. CC]));


• VM1, VM2, … , VMVC – інформації про правила відображення керуючого елемента, пов’язаного з даною величиною (тип даних – структура).


Зазначені два набори даних (State) разом з поточним унікальним ідентифікатором ресурсу (URI) і маркованих документом в двійковому представленні (Doc) повністю описують поточний стан програми-браузера. У цьому випадку інформаційний граф моделі обробки даних представлений на рис. 3.


Тут процес Cache виробляє вибірку з кешу документа по його унікальному ідентифікатору, процес Load виконує завантаження документа за допомогою протоколу HTTP, процес Parse виконує розбір маркованого документа і на його основі заповнює набір даних State. Процес Request виробляє збірку нового унікального ідентифікатора на основі наступних даних:


• значення URLj, пов’язаного з обраною користувачем командою (вважаємо, що її індекс – j);


• імен VNki і поточних значень VVki величин, пов’язаних з обраною користувачем командою (тобто тих, для яких виконується умова VRki = j).


Зазначимо, що для мови HTML правила побудови унікального ідентифікатора мають такий вигляд:


URI ” = URLj + “?” + VNk1 + “=” + VVk1 + “&” + VNk2 + “=” + VVk2 + “&” + … + VNkn + “=” + VVkn.


Протоколи прикладного рівня HTTP і SQL * Net


Протоколи прикладного рівня HTTP (Hyper Text Transfer Protocol) і SQL * Net досить схожі (знаходяться на одному рівні класичної моделі OSI). Спільними функціями цих протоколів є:


• узгодження параметрів транспортного кодування (у тому числі компресії) даних;


• узгодження параметрів кодування алфавіту національної мови;


• дозвіл імен прикладного рівня в ідентифікаторах ресурсів.


Відмінності проявляються в схемах кодування переданої на нижні рівні інформації, а також у характері повертається від сервера метаінформації.


Процес HTTP-клієнт ініціалізується шляхом завдання параметра URI – унікального ідентифікатора запитуваного ресурсу. При цьому процес виконує розбір код на три параметри:


• ім’я хоста;


• TCP-порт HTTP-сервера;


• відносний URI.


При необхідності ім’я хоста представляється відповідним IP-адресою. У цьому випадку використовуються:


• служба розв’язання доменних імен (DNS);


• служба розпізнавання імен Windows (WINS);


• локальний довідник.


Далі процес визначає список допустимих для нього параметрів HTTP-з’єднання, таких, як транспортний кодування (стиснення) і кодування національного алфавіту. У HTTP-запиті вказується весь список для того, щоб HTTP-сервер мав можливість вибрати загальні для клієнта і сервера параметри з’єднання. У разі присутності документа з аналогічним унікальним ідентифікатором в локальному кеші в HTTP-заголовок додається поле “Час створення наявного в кеші документа”. Сформований текст HTTP-запиту (із зазначенням типу – “GET”, версії протоколу “HTTP/1.1”, відносного URI, імені хоста і параметрів з’єднання) передається на нижележащий рівень стека мережевих протоколів.


Після отримання запиту HTTP-сервером процес перевіряє наявність на сервері ресурсу з замовленим ідентифікатором. При відсутності запитуваної ресурсу на клієнтську сторону передається повідомлення з кодом помилки “404” – “Документ не знайдено”. У разі наявності ресурсу можливі три варіанти.


Якщо HTTP-запит містив поле “Час створення наявного в кеші документа” і вказане в ньому час збігається з часом створення зберігається на серверній стороні ресурсу, то на клієнтську сторону передається повідомлення з кодом “304” – “Документ не змінювався”. В іншому випадку на підставі свого списку можливих параметрів HTTP-з’єднання і списку, отриманого в HTTP-запиті, сервер вибирає активні параметри з’єднання. Якщо не вдається узгодити параметри з’єднання, то на клієнтську сторону відправляється повідомлення про помилку з кодом “406” – “Несогласуемие параметри”. При успішному узгодженні параметрів формується HTTP-відповідь, що включає код “200” (“Ресурс передається”), вміст (при необхідності перетворене згідно активним параметрами), записи про активні параметрах з’єднання, а також інформацію про дату і часу створення документа для занесення в кеш на стороні клієнта.


Повний текст HTTP-відповіді передається на нижележащий рівень стека протоколів. Після отримання відповіді на клієнтської частини системи перевіряється відповідність довжини вмісту, і при необхідності виконується транспортне декодування.


Зазначимо, що протокол SQL * Net об’єднує кілька подпротоколов, що відповідають за різні функції в організації взаємодії “клієнт – сервер” і “сервер – сервер”.


Подпротокол-інтерфейс UPI / OPI / NPI надає можливість у з’єднанні “клієнт – сервер” (UPI / OPI) і “сервер – сервер” (NPI / OPI) виконувати команди прикладного рівня:


• підключення до сервера;


• попередня перевірка сервером синтаксису SQL-запиту;


• виконання SQL-запиту;


• відкриття курсора реляційного представлення даних;


• передача реляційних даних від сервера до клієнта;


• типізація переданих даних на основі записів про типи даних на стороні сервера;


• закриття курсора;


• відключення від сервера.


При цьому відмінність схем підключення “клієнт – сервер” і “сервер – сервер” проявляється тільки на цьому рівні, тоді як на більш низьких рівнях подпротоколов відмінності відсутні. Сервер, що відповідає на SQL-запит, в обох випадках використовує інтерфейс OPI – аналог процесу HTTP-сервера. Викликають інтерфейси UPI (клієнтський) і NPI (серверний при з’єднанні “сервер – сервер”) відрізняються незначно. З боку клієнта уніфіковані драйвери доступу до реляційних даних (такі, як, наприклад, ODBC – Open DataBase Connection) виробляють відображення своїх інтерфейсів до інтерфейсу UPI.


Подпротокол Two-Task Common (TTC) відповідає за вибір єдиного уявлення типів даних і схем кодування національного алфавіту. У разі необхідності як клієнтська, так і серверна сторона TTC може проводити перетворення переданих даних в рамках відомих їй схем кодування. На відміну від схеми, використовуваної протоколом HTTP, Two-Task Common робить вибір загальних параметрів SQL * Net-з’єднання, одноразово в момент його відкриття і при виконанні всіх подальших команд користується вже узгодженими (актуальними) параметрами.


Подпротокол Transparent Network Substrate (TNS) реалізує не залежить від нижчого стека мережевих протоколів інтерфейс з чотирма командами:


• підключитися до віддаленого об’єкту;


• передати дані;


• отримати дані;


• відключитися від віддаленого об’єкта.


У функції TNS входить вирішення імен об’єктів з тим, щоб вищерозміщені рівні могли оперувати абстрактним поняттям “псевдонім” віддаленого процесу. Дозвіл імен проводиться за допомогою наступних протоколів:


• Oracle Names;


• локальний довідник;


• програмні адаптери від Oracle для популярних протоколів дозволу імен (NetWare Directory Service, StreetTalk, NIS і т. п.).


У зв’язку з однотипністю функцій, які виконуються протоколами, опишемо для них єдину модель функціонування процесу, поширивши на весь протокол SQL * Net можливості кешування результатів (можливістю кешування результатів володіє тільки стик інтерфейсів NPI / OPI). До HTML-документу і даними в реляційному поданні далі будемо застосовувати термін “ресурс”.


Нехай стан системи “клієнт – сервер” описується таким набором величин:


• RN – ім’я запитуваної у клієнтського інтерфейсу ресурсу (тип даних – рядковий);


• RS – необхідна кодування національного алфавіту запитуваного ресурсу (тип даних – цілочисельний);


• CS – список кодувань національного алфавіту, підтримуваних клієнтом (тип даних – список цілочисельних величин);


• CT – список транспортних кодувань, підтримуваних клієнтом (тип даних – список цілочисельних величин);


• CC – вміст ресурсу на стороні клієнта (вихідний результат процесу) (тип даних – рядковий);


• CD – дата і час створення ресурсу (тип даних – позначка часу);


• CACHE_CNT – кількість ресурсів, розміщених в кеші (тип даних – цілочисельний);


• CACHE_NAMES – імена ресурсів, розміщених в кеші (тип даних – список строкових величин);


• CACHE_DATES – дата і час створення ресурсів, розміщених в кеші (тип даних – список відміток часу);


• CACHE_VALUES – вміст ресурсів, розміщених в кеші (тип даних – список строкових величин);


• CACHE_CHARSETS – кодування національної мови ресурсів, розміщених в кеші (тип даних – список цілочисельних величин);


• CI – номер знайденого в кеші ресурсу (тип даних – цілочисельний);


• CB – буфер клієнтської сторони (тип даних – рядковий);


• SB – буфер серверної сторони (тип даних – рядковий);


• TN – ім’я запитуваного ресурсу на серверній стороні (тип даних – рядковий);


• TS – список кодувань національного алфавіту, підтримуваних клієнтом, на серверній стороні (тип даних – список цілочисельних величин);


• TT – список транспортних кодувань, підтримуваних клієнтом, на серверній стороні (тип даних – список цілочисельних величин);


• TDATE – дата і час створення ресурсу, знайденого у кеші (тип даних – позначка часу);


• SS – список кодувань національного алфавіту, підтримуваних сервером (тип даних – список цілочисельних величин);


• ST – список транспортних кодувань, підтримуваних сервером (тип даних – список цілочисельних величин);


• VALUE_CNT – кількість ресурсів, розміщених на сервері (тип даних – цілочисельний);


• VALUE_NAMES – імена ресурсів, розміщених на сервері (тип даних – список строкових величин);


• VALUE_DATES – дата і час створення ресурсів, розміщених на сервері (тип даних – список відміток часу);


• VALUE_VALUES – вміст ресурсів, розміщених на сервері (тип даних – список строкових величин);


• VALUE_CHARSETS – кодування національної мови ресурсів, розміщених на сервері (тип даних – список цілочисельних величин);


• SI – номер знайденого на сервері ресурсу (тип даних – цілочисельний);


• AS – кодування національного алфавіту, обрана сервером як активна для даного сеансу (тип даних – цілочисельний);


• AT – транспортна кодування, обрана сервером як активна для даного сеансу (тип даних – цілочисельний);


• DS – кодування національного алфавіту, обрана сервером як активна для даного сеансу, на стороні клієнта (тип даних – цілочисельний);


• DT – транспортна кодування, обрана сервером як активна для даного сеансу, на стороні клієнта (тип даних – цілочисельний);


• CM – буфер на клієнтській стороні для вмісту ресурсу в ході перекодіровок (тип даних – рядковий);


• SM – буфер на серверній стороні для вмісту ресурсу в ході перекодіровок (тип даних – рядковий);


• CE – код відповіді сервера на стороні клієнта (тип даних – цілочисельний).


Додатково введемо константи:


• С202 – код відповіді, відповідний успішну відправку ресурсу сервером;


• С304 – код відповіді, відповідний незмінності ресурсу з моменту останнього завантаження його клієнтом;


• С404 – код відповіді, відповідний відсутності ресурсу;


• С406 – код відповіді, відповідний несогласуемості параметрів клієнтської і серверної сторони.


Інформаційний граф протоколів в рамках даної моделі представлений на рис. 4.


Іменні процедури в моделі мають наступні функції:


• ENC_REQ – кодування запиту;


• DEC_REQ – декодування запиту;


• ENC_RESP – кодування відповіді;


• DEC_RESP – декодування відповіді;


• CHARSET – зміна схеми кодування алфавіту національної мови;


• ENC_TRANS – транспортне кодування;


• DEC_TRANS – транспортне декодування.


Операції присвоювання SB = CB і CB = SB представляють собою передачу повідомлень по мережі TCP / IP.


Протокол транспортного рівня TCP


Розрізняють дві основні функції протоколу TCP (transmission control protocol):


• підтвердження доставки повідомлення від відправника одержувачу;


• управління швидкістю обміну даними.


Для реалізації названих функцій в протоколі було введено поняття “вікно” – максимальний обсяг даних, який може бути переданий без підтвердження з приймаючої сторони. В процесі передачі даних розмір вікна варіюється виходячи з мережевої обстановки: при збільшенні ефективної пропускної здатності мережі передавальна сторона збільшує розмір вікна, при зниженні – зменшує.


Крім того, для гарантованої доставки повідомлень між клієнтської і серверної стороною на час передачі повідомлення встановлюється унікальний сеанс, в рамках якого пересилаються пакети квитирования – Підтвердження доставки. Початок сеансу запитується клієнтської стороною службовим пакетом SYN з вмістом нульової довжини, а підтверджується з боку сервера пакетом SYN_ACK також з вмістом нульової довжини. Кінець сеансу запитується службовим пакетом FIN і підтверджується пакетом FIN у зворотному напрямку.


Виходячи з симетричності протоколу TCP, для цілей, поставлених у цій роботі, досить побудувати модель TCP-з’єднання, що передає дані в одному напрямку (скажімо, від зухвалої сторони до викликається).


Опишемо стан системи “TCP-клієнт – TCP-сервер” наступними величинами:


• кількістю вікон N, на які буде розбито передане повідомлення (тип даних – цілочисельний);


• значенням вікон S1, S2, … SN на передавальній стороні (розмір вікон в бітах може бути непостійний, але для даного завдання це не грає ролі) (тип даних – список строкових величин);


• буфером передавальної сторони SB розміром в одне вікно (тип даних – рядковий);


• порядковим номером поточного переданого вікна SI (тип даних – цілочисельний);


• значенням вікон R1, R2, … RN на приймаючій стороні (тип даних – список строкових величин);


• буфером приймаючої сторони RB розміром в одне вікно (тип даних – рядковий);


• порядковим номером поточного прийнятого вікна RI (тип даних – цілочисельний).


Крім того, введемо службові значення буферів прийому та передачі, які відповідають за початок і закінчення сеансу:


• SYN – запит на встановлення з’єднання;


• SYN_ACK – підтвердження встановлення з’єднання;


• ACK – підтвердження прийому вікна повідомлення;


• FIN – сигнал закінчення повідомлення.


Інформаційний граф протоколу TCP в рамках введених позначень представлений на рис. 5. Операції присвоєння SB = RB і RB = SB представляють собою передачу вікон по мережі за допомогою протоколу IP.


Протокол мережевого рівня IP


Протоколи мережного рівня відповідають за відносно незалежну для вищих рівнів моделі OSI передачу повідомлень по мережах з гетерогенною структурою протоколів канального рівня (Ethernet, FrameRealy, ATM, PPP і т. д.). Як наслідок, в їх функції входить маршрутизація пакетів в просторі імен мережевого рівня, а також фрагментація і складання пакетів (у зв’язку з варійованої максимально можливої ​​довжини пакета в різних протоколах канального рівня).


В рамках поставленої задачі критичною функцією з перерахованих вище є саме фрагментація і складання пакетів протоколом IP. При цьому при побудові моделі необхідно враховувати, що в силу неоднорідності мережевих умов в часі черговість приходу пакетів-фрагментів в пункт призначення може бути довільною. Цим протокол IP якісно відрізняється від протоколу TCP, який реалізує сувору послідовність передачі вікон.


Стан системи “відправник – одержувач” при передачі одного пакета протоколу IP опишемо наступними величинами:


• кількістю фрагментів N, на які буде розбито передане повідомлення (тип даних – цілочисельний);


• значенням пакетів-фрагментів S1, S2, … SN на передавальній стороні (тип даних – список строкових величин);


• порядковим номером поточного переданого фрагмента SI (тип даних – цілочисельний);


• мережевим буфером B розміром, рівним максимально можливій довжині IP-повідомлення (тип даних – список строкових величин);


• значенням пакетів-фрагментів R1, R2, … RN на приймаючій стороні (тип даних – список строкових величин);


• значенням буфера RB на приймальній стороні розміром в один фрагмент (тип даних – рядковий);


• значенням номера прийнятого пакету на приймальній стороні PI (тип даних – цілочисельний).


У цьому випадку інформаційний граф протоколу IP має такий вигляд (рис. 6). Операції присвоювання та читання з буфера B являють собою передачу вікон по мережі за допомогою протоколу нижчого рівня. Для операції читання з буфера B існують обмеження: не можна вважати j-ий елемент буфера B, якщо лічильник SI менше j.


Зазначимо, що іменні процедури в моделі мають наступні функції:


• FRAG – фрагментованість повідомлення на елементи Si;


• DEFRAG – складання повідомлення з елементів Ri, перевірка повного прийому на основі порядкових номерів фрагментів;


• ENC_IP – кодування IP-фрагмента;


• DEC_IP – декодування IP-фрагмента.


Характерною особливістю інформаційного графа протоколу IP є недетермінірованность його поведінки за рівних початкових умовах. Приклад графа станів системи для кількості фрагментів, рівного двом, наведено на рис. 7.


Трохи теорії моніторингу безпеки ERP-систем


Проведемо аналіз отриманих моделей обробки даних за допомогою методів аналізу розмірностей і подібності. Дані методи були спочатку розроблені авторами для аналітичної верифікації програм і грунтуються на перевірці спільності системи розмірностей моделі обробки даних ERP Oracle E-Business Suite.


Коротко суть пропонованих методів полягає в тому, що для інформаційного графа моделі обробки даних ERP Oracle E-Business Suite будується система взаємозв’язків між розмірностями змінних і констант наступним чином. Кожен оператор моделі, що містить обчислювальні операції та / або оператор присвоювання і має однорідний вигляд відносно своїх аргументів, представляється у вигляді суми функціоналів ?: u = 1, 2, …, r, де (1) і (2) (3)


У цьому випадку положення теорії розмірностей і подібності [1] дозволяють створити систему вимог до розмірності величин xj, що випливає з наступних міркувань (запис [X] позначає “розмірність величини X”): (4) (5) (6) (7)

і після логарифмування (8)

u = 1, 2, …, r ; s = 1, 2, …, (q-1) .


Необхідною критерієм семантичної правильності моделі обробки даних ERP Oracle E-Business Suite є існування в системи (8) рішення, в якому жодна з змінних (ln [xj]) не звернена в нуль. Проблемам підвищення швидкості обчислення даного критерію буде присвячений один з наступних матеріалів. У даній же статті для вирішення цього питання ми обмежимося тривіальними еквівалентними перетвореннями рівнянь системи, записаної в матричній формі.


Таким чином, для побудови початкового набору рівнянь (2) для кожної моделі обробки даних ERP Oracle E-Business Suite пропонується наступна методика:


• довільно візьмемо вибірку реалізацій процесу, що описується моделлю;


• перевіримо показність вибірки по покриттю всіх вершин керуючого графа моделі;


• виконаємо приведення керуючого графа моделі з метою виділення обчислювальних операторів з операторів перевірки умов та організації циклів;


• виділимо з вибірки всі унікальні оператори, що відповідають описаним вище обмеженням на вигляд функціонального зв’язку;


• виділимо задіяні в операторах змінні і константи, вважаючи при цьому:


а) елементи всередині масиву равноразмернимі величинами,


б) числові константи попарно різнорозмірними величинами (визначення їх приналежності певним класам відбудеться автоматично на етапі узгодження матриці розмірностей).


Переходи керуючого графа, пов’язані з обчисленням складних функціональних залежностей, і відповідні операторам виклику підпрограм доповнюють систему (2) наборами операцій привласнення формальних параметрів. Подібні додаткові обмеження виконують сполучну роль між величинами основного тіла алгоритму і величинами підпрограм. Даний крок необхідно виконувати в разі побудови єдиної моделі обчислювального процесу.


Моніторинг безпеки ERP Oracle E-Business Suite


Моніторинг безпеки SQL-запитів. Як правило, під прикладної програмою розуміється процес, що виконується на сервері додатків (“середня ланка” триланкової моделі) і відповідальний за реалізацію власне прикладної логіки системи. Послідовність операцій, виконуваних даним процесом за запитом, представлена ​​на рис. 8.



Вважаючи, що алгоритм обчислень шляхом нескладних перетворень можливо привести до нормалізованої (розділеної) формі, приймемо за властивості першого і останнього блоків відсутність в них перетворень розмірностей інформації. Таким чином, у схемі, наведеній на рис. 1, Контролю підлягають наступні два рівні системи.


• Блоки перед-і поствичісленій. Вони зазвичай реалізуються на універсальних мовах високого рівня (С + +, Pascal, Java, C #). Контролю підлягають інваріанти арифметичних операцій і операторів присвоювання.


• SQL-запит. Мова структурованих запитів SQL (Structured Query Language) являє собою прикладної мова високого рівня. Контролю (на основі методу контролю розмірностей) підлягають інваріанти кількох груп типових операцій мови, які залучають різні типи даних.


Давайте розглянемо можливості контролю SQL-запитів.


Пропозиції мови SQL, надзвичайно широко застосовується на сьогоднішній день для уніфікації доступу до реляційних СУБД, є команди серверу БД на отримання доступу або редагування зберігаються даних. Найбільш часто застосовуються чотири основні типи пропозицій:


• SELECT – вибірка рядків даних;


• INSERT – додавання нових рядків;


• UPDATE – редагування існуючих рядків;


• DELETE – видалення рядків.


Елементи контекстно-вільних граматик, що породжують вищеперелічені пропозиції, в графічній формі подання зображені на рис. 9-12. Правила виведення, що породжують нетермінальні символи, які не впливають на процедуру аналізу розмірностей, опущені.


Пропозиції мови SQL містять два типи конструкцій, контрольованих на рівні інваріантів розмірностей:


• конструкції condition (“умова”);


• конструкції неявного відповідності розмірностей.


Конструкції “умова” зустрічаються в SQL-пропозиції SELECT, UPDATE і DELETE (позиції C 1, C 2, C 3, C 4 на рис. 9, позиція C 1 на рис. 11 і позиція C 1 на рис. 12). Мова SQL підтримує кілька типів умов, проте всі вони представимо, як і в переважній більшості універсальних мов програмування, або в одномісній формі


(“Операція умови”

“Вираз-1”) (1)


або в двомісній формі


(“Вираз-1” “операція умови”

“Вираз-2”). (2)


Виняток становлять специфічні умови ANY, SOME, ALL, IN, що залучають у себе вкладені пропозиції SELECT.


Аналіз розмірностей перших двох класів умов повністю аналогічний методикою, розглянутою вище:


• вираження приводяться до однорідним рівнянням;


• кожне рівняння з q доданками перетворюється в (q -1) вимог рівності розмірностей однорідних доданків;


• отримані рівняння розмірностей логаріфміруются, в результаті чого створюється система однорідних лінійних рівнянь (назвемо її AC), що описує вимоги до взаємозв’язкам між розмірностями.


Специфічним для мови SQL є побудова системи рівнянь розмірностей AE, що грунтується на конструкціях неявного відповідності розмірностей і конструкціях умов ANY, SOME, ALL, IN. Основний ідеологією мови SQL є робота з кортежами – порядкова обробка записів таблиць і результатів реляційних відносин над ними. Так, в пропозиції SELECT кортежами є нетермінальні символи, позначені E 1 і E 2 на рис. 2, в реченні INSERT – E 1, E 2, E 3 та E 4 на рис. 3, в пропозиції UPDATE – E 1, E 2, E 3, E 4 і E 5 на рис. 4. У будь-якому реченні мови SQL елементи всіх описаних кортежів повинні мати попарно рівні розмірності.


Крім того, аналогічні обмеження накладаються і на елементи умов спеціального виду ANY, SOME, ALL, IN. У загальному вигляді ці умови можна представити у формі


(“Кортеж-1” “операція умови” “ANY / SOME / ALL / IN” “кортеж-2”).


Таким чином, наявність в реченні мови SQL n описів кортежів з k елементів в кожному (3)


вводить систему з (n -1) xk додаткових обмежень на розмірності стовпців таблиць і виразів, що їх містять. У тих випадках, коли елементом кортежу є не власне стовпець таблиці, а арифметичне вираз, що містить його, можливо ще більше збільшення системи обмежень (згідно з методикою контролю розмірностей однорідних рівнянь).


Побудована з отриманого списку обмежень система рівнянь розмірностей AE доповнює отриману раніше систему AC. Вимога нетривіальною спільності системи A, утвореною шляхом злиття систем AE і AC, є потужним засобом перевірки семантичної коректності SQL-речення перед його виконанням.


     Приклад


Зробимо побудова системи рівнянь розмірності A і контроль коректності конкретного SQL-пропозиції на наступному прикладі. Дана СУБД, яка містить таблицю DETAILS з полями (табл. 1).


Крім того, в системі визначені наступні константи (табл. 2).


Припустимо, що була зроблена спроба виконати наступний SQL-запит:


UPDATE DETAILS


SET (S,VALUE) = (X*Y, X*Y*PRICE+TRANS)


WHERE ((X,Y) IN (SELECT X+MARGIN,Y+MARGIN


FROM DETAILS)) AND


(PRICE*MAX_SIZE>TRANS)


В основному реченні UPDATE присутні два кортежу по два елементи в кожному, одне неспецифічне умова і одна специфічна умова IN. У умови IN і в зв’язаному їм запиті SELECT визначено ще два кортежу по два елементи в кожному.


Таким чином, перевірка конструкцій “умова” дає рівняння розмірностей


[ PRICE * MAX _ SIZE ]=[ TRANS ] , (4)


перевірка конструкцій узгодження розмірностей –


[S] = [X * Y] і (5)


[VALUE]=[X*Y*PRICE+TRANS] . (6)


Вкладене пропозицію SELECT призводить ще до двох рівнянь розмірності:


[X] = [X + MARGIN] і (7)


[Y]=[Y+MARGIN] . (8)


В цілому система рівнянь AC, породжувана рівнянням (4), має вигляд (табл. 3).


Система рівнянь розмірності AE, породжувана рівняннями (5-8), має вигляд (табл. 4.


Матриця, відповідна системі A (утворюється об’єднанням AC і AE) має розмірність 6×8 і ранг 6, що характеризує наявність у системі двох незалежних розмірностей (в якості незалежних можуть, наприклад, бути вибрані X і VALUE). Це повністю узгоджується з предметною областю, де визначені дійсно рівно дві незалежні розмірності: “метри” і “рублі”.


Припустимо, що на етапі створення ПЗ або розбору динамічного HTTP-запиту сталася помилка, яка спричинила таке написання SQL-пропозиції перед моментом виконання:


UPDATE DETAILS


SET (S,VALUE) = (X*Y, X*Y*PRICE+TRANS)


WHERE ((X,Y) IN (SELECT X+MARGIN,Y*MARGIN FROM DETAILS)) AND


( PRICE * MAX _ SIZE > TRANS )


У момент аналізу зміни піддасться рівняння (8). Воно набуде вигляду


[ Y ]=[ Y * MARGIN ] . (9)


Матриця, відповідна новій системі, має розмірність 6×8 і ранг 6, що також характеризує наявність у системі двох незалежних розмірностей.


Однак при цьому мають місце нульові значення у векторі-рішення, що відповідає нібито наявним наступним взаємозв’язкам:


[ X ] = [ MARGIN ] = 0 . (10)


Це вже кардинально не відповідає предметної області і є однозначним індикатором аномалії в побудованій SQL-конструкції.


Моніторинг безпеки прикладних протоколів ERP Oracle E – Business Suite. Вибірка реалізацій процесу протоколу прикладного рівня, представницька по покриттю вершин керуючого графа, містить такі унікальні взаємозв’язку між розмірностями в явному вигляді.


Крім того, приведення операторів перевірки умов виділяє ще один набір обмежень на розмірності:


[RN]=[CACHE_NAMES]


[TN]=[VALUE_NAMES]


[VALUE_DATES]=[TDATE]


[CI]=[CACHE_CNT]


[ SI ]=[ VALUE _ CNT ]


(У всіх випадках в якості ідентифікаторів елементів масивів виписані імена самих масивів, виходячи з принципу равноразмерності елементів масивів, а знаки “*” у числових констант відзначають їх потенційну різнорозмірних).


Система рівнянь (8) для протоколу прикладного рівня, записана в матричній формі, являє собою матрицю AL 7 розмірності 29×36. Ранг матриці дорівнює 28, що обумовлено наявністю одного лінійно залежної рівняння. Традиційна методика обчислення критерію вимагає приведення матриці шляхом еквівалентних перетворень до спеціального виду з виділеними базисними стовпцями. Однак для зручності викладу результатів для даної моделі в журнальному форматі, ми змінимо вихідні позиції стовпців змінних і наведемо матрицю AL 7 до блочно-діагонального вигляду B `L 7: де (9) (9.1) (9.2) (9.3) (9.4) (9.5) (9.6) (9.7) (9.8)


(Над стовпцями підписані величини, відповідні xj в невідомих ln [xj] системи (8)).


Матриця має 8 незалежних (базисних) і 28 залежних шпальт; нульова рядок, що відповідає лінійно залежному рівнянню вилучена. Очевидно, що система однорідних лінійних рівнянь, що описується матрицею B “L 7, має рішення, що не містить нулів. Як наслідок, подібне рішення має і вихідна система розмірностей моделі.


Моніторинг безпеки протоколу TCP .


Наявність циклу і розгалуження в керуючому графі процесу вказує на можливість досить великої кількості різних реалізацій. Нас буде цікавити вибірковий набір реалізацій, що покриває всю сукупність вершин керуючого графа. Даному умові задовольняє набір з однієї реалізації, хоча б одноразово проходить цикл процесу, тому далі будемо розглядати подібні реалізації як представницькі для даного керуючого графа.


У явному вигляді в моделі процесу протоколу TCP присутні наступні взаємозв’язки між розмірностями:


Крім цього, приведення умови розгалуження циклу (SI

[ N ] = [ SI ].


Матрична форма AL 5 записів системи (8) для даного протоколу наведена в таблиці 7. У заголовках стовпців вказані відповідні змінні xj.


Матриця має розмірність 11×13. Ранг матриці дорівнює 10, що відповідає одній лінійно залежною рядку (в даному випадку рядок 4 є інверсією рядка 2). Шляхом еквівалентних перетворень наведемо матрицю до вигляду BL 5, що складається з базисних стовпців і залежних стовпців, що містять по одному одиничному елементу (табл. 8).


Спеціальний вид матриці дозволяє безпосередньо вказати не містить нулів рішення системи розмірностей моделі. Для цього досить вибрати в якості набору значень базисних величин будь-який, не містить нульових координат вектор, який не є ортогональним до векторів, складеним порядково з коефіцієнтів базисних стовпчиків.


Моніторинг безпеки протоколу IP .


Представницька вибірка реалізацій для протоколу IP містить наступні взаємозв’язки між розмірностями величин в явному вигляді:


[S]=[RB] [PI]=[SI] [RI]=[1**]


[RB]=[R] [SI]=[1*]


Крім того, оператори умови містять ще два обмеження на розмірності:


[SI] = [N] і [RI] = [N].


Матрична форма запису AL 3 системи рівнянь (8) для даної моделі наведена в таблиці 9, формат запису відповідає формату попереднього пункту.


Матриця має розмірність 7×9, ранг матриці – 7. Шляхом еквівалентних перетворень наведемо матрицю до спеціального виду BL 3 (таблиця 10).


Аналогічно до попереднього розділу спеціальний вид матриці підтверджує наявність несодержащего нулів рішення і, як наслідок, виконання досліджуваного критерію семантичної коректності моделі.


Таким чином, стає можливим здійснювати моніторинг безпеки моделей мережевої взаємодії в ERP Oracle E – Business Suite на основі TCP / IP. Істотним достоїнством пропонованого методу є вироблення необхідних критеріїв семантичної коректності моделі обробки даних в ERP Oracle E – Business Suite.


Висновок


Відомо, що своєчасність та правильність моніторингу безпеки ERP Oracle E – Business Suite в чому визначає ефективність управління технологіями та організаційно-технічними засобами захисту інформації. Вивчення специфіки такого завдання вказує на необхідність виділення і контролю інваріантів коректною (правильної з точки зору безпеки) обробки даних в ERP Oracle E – Business Suite. У пропонованому методі моніторингу безпеки узагальнені, систематизовані і розвинуті практичні результати моніторингу стану захищеності типової системи ERP Oracle E – Business Suite в вітчизняних підприємствах. Важливим моментом цього методу є розвиток стандартних технологій і засобів захисту ERP Oracle E – Business Suite, що надають можливість контролю стану захищеності на основі інваріантів безпечної обробки даних корпоративної системи в реальному масштабі часу, що враховують бізнес-логіку конкретного підприємства. Узагальнюючи сказане вище, слід зауважити, що всі викладені результати служать єдиної мети – створення нового, більш ефективного і обгрунтованого практично підходу до моніторингу безпеки ERP Oracle


E – Business Suite. Пропонований підхід може бути корисний керівникам, їх заступникам з розвитку, автоматизації та безпеки, начальникам служб автоматизації та інформаційної безпеки, а також всім особам, відповідальним за організацію інформаційної безпеки ERP Oracle


E – Business Suite на підприємстві при виконанні рекомендацій та вимог керівних та нормативних документів Держтехкомісії Росії, ФАПСИ, а також міжнародних стандартів, головним чином, ISO 17799 ( BS 7799), ISO 15408, ISO 9001:9002, BSI .

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*