А В Бєгун - Аспектно-орієнтована технологія оптимізації захисту додатків web-порталу - страница 1

Страницы:
1 

Література.

1. Сальніков В. Н. Бізнес-планування та організація фінансово-господарської діяльності підприємства: Навчальний посібник. — 3-е вид. доп. і випр. — К.: Альтера, 2006. — 520 с.

2. Верченко П. І. Багатокритеріальність і динаміка економічного ри­зику (моделі та методи): Монографія. — К.: КНЕУ, 2006. — 272 с.

3. Верченко П. І. Багатокритеріальні моделі в інтелектуальних систе­мах прийняття рішень. — Моделювання та інформ. системи в економіці: Зб. наук. пр./відп. ред. В. К. Галіцин. — 2008. — Вип. 78. — Ст. 36—44.

4. Верченко П. І. Принцип максимального відхилення як критерій прийняття багатокритеріальних рішень. — Економічна кібернетика: міжнародний науковий журнал. — 2001. — № 1—2. — С. 16—24.

5. Камінський А. Б. Моделювання фінансових ризиків: Монографія. — К.: Видавничо-поліграфічний центр «Київський університет», 2006. — 204 с.

6. Бізнес-планування підприємницької діяльності в умовах неви­значеності та ризику. — Х: Фактор, 2006 — 480 с.

УДК 621.391 (075.8)

А. В. Бєгун, канд. екон. наук,

ДВНЗ «Київський національний економічний університет імені Вадима Гетьмана»

АСПЕКТНО-ОРІЄНТОВАНА ТЕХНОЛОГІЯ ОПТИМІЗАЦІЇ ЗАХИСТУ ДОДАТКІВ WEB-ПОРТАЛУ

Анотація. В статті розглянуто аспектно-орієнтований підхід створен­ня захищених програмних систем складної структури. Основу цього під­ходу складає аспектно-системний модуль, в який внесена наскрізна фун­кціональність. Аспект відображає аудит, використання якого оптимізує захист додатків при їх розробці.

ANNOTATION. The article deals with Aspect-oriented approach to creating secure software systems with complex structures. The basis of this approach is Aspect-system module, which included cross-functionality. Aspect audit shows that optimizes protection applications in their development

Ключові слова. Web-портал, аспект, наскрізна функціональність, аудит, інтегратор аспектів, Java-сервлети.

Сучасний Web-портал неможливий без використання Web-додатків, на які часто спрямовують свої атаки зловмисники. Web-додатки стають усе більшь розповсюдженими й усе більше склад­ними, відіграючи в такий спосіб основну роль у більшості онлай-нових проектів. За оцінками фахівців, близько 70 % часу в проек-

© Бєгун А. В., 2010

189тах витрачається на супровід і внесення змін у готовий програм­ний код. Тому досить важливою і актуальною стає роль захисту додатків та її оптимізація на базі новітніх технологій, наприклад, аспектно-орієнтованого програмування (АОП) і подібних транс­формаційних підходів.

Як правило, будь-яка програмна система складається з кількох частин: основної (предметно-орієнтованої) і системної частини, які несуть у собі необхідну функціональність. Наприклад, ядро системи обробки кредитних карток призначено для роботи із платежами, тоді як функціональність системного рівня призначе­на для ведення журналу подій, цілісності транзакцій, авторизації, безпеки, продуктивності й т.д. Більшість подібних частин систе­ми, відома як наскрізна функціональність, стосуються безлічі ос­новних предметно-орієнтованих модулів. Тобто, складну програ­мну систему можна розглядати як комбінацію модулів, кожний з яких містить у собі крім бізнес-логіки частину наскрізної функці­ональності з набору вимог до системи (рис. 1).

Робота з БД та перманентними об'єктами

ТУ

Програмні модулі

Рис. 1. Система як набір функціональних модулів

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

Розробник створює програмну систему як результат обробки безлічі вимог. Можна явно виділити із цієї множини вимоги до логіки конкретного модуля й загальносистемні. Багато із систем­них вимог можуть бути ортогональними один до одного та вимо­гам конкретного модуля. Вимоги системного рівня мають тенден­цію перетинатися з безліччю основних вимог. Наприклад, типова система рівня підприємства містить у собі такі види наскрізної функціональності, як ведення журналу подій, управління ресурс­ним пулом, адміністрування, аналіз продуктивності й керування носіями інформації. Кожне із цих вимог до системи торкається безлічі підсистем, наприклад, вимога з управління носіями інфо­рмації торкається зберіганню кожного бізнес-об'єкту.

Сучасні технології розробки програмного забезпечення на рів­ні мов програмування надають зручні засоби для виділення логі­ки функціонування програми в окремі модулі, але жодна з них не пропонує зручного способу локалізації в окремі модулі функціо­нальності, яка повинна поширюватися на всю систему [1]. Через те, що реалізація наскрізної функціональності не може бути відо­соблена засобами мови програмування в окремому програмному модулі, елементи цієї реалізації присутні в тому або іншому виді у більшості модулів, що утворюють програмну систему. Розгля­немо приклад java-класу, основним завданням якого є реалізація деякої логіки:

public class SomeBusinessClass {

// Бізнес-дані // допоміжні дані

public void

performSomeOperation(OperationInformation info) {

// перевірити рівень доступу до даних

// перевірити відповідність вхідних даних контракту

// заборонити доступ до даних інших потоків виконання

// перевірити стан кеша даних

// занести в журнал оцінку про початок операції

// ==== Реалізація логіки даного класу ====

// занести в журнал оцінку про кінець операції

// дозволити доступ до даних інших потоків виконання

}

}

У цьому прикладі можна виділити дві проблеми. По-перше, обумовлені допоміжні дані не ставляться до вимог, що накладають­ся на даний модуль, а потрібні для роботи наскрізної функціональ­ності. По-друге, реалізація performSomeOperation(..) виглядає більш навантаженою, чим просто «Реалізація логіки даного класу». Для правильної роботи даного методу за вимогами необхідно виконати ряд дій, що не ставляться конкретно до даного модуля — перевіри­ти рівень доступу до даних, перевірити відповідність вхідних даних контракту, заборонити доступ до даних інших потоків виконання, перевірити стан кеша даних, занести в журнал оцінку — це вимоги системного рівня. До того ж, багато хто із цих загальних вимог по­винні бути реалізовані в інших модулях.

Аспектом в АОП є системний модуль, у який винесена на­скрізна функціональність. Аспектний модуль — це результат ас­пектної декомпозиції, на етапі якої виявляються які-небудь яви­ща, поняття, події які можуть бути застосовані до групи ком­понентів, отриманих після об' єктної декомпозиції. Аспект являє собою язикову концепцію, схожу із класом, але тільки більше ви­сокого рівня абстракції [2, 3].

Аспекти можуть зачіпати багато компонентів і використають так називані крапки вставки для реалізації регулярних дій, які звичайно розосереджені по всьому тексту програми. В аспектно­му модулі описуються зрізи крапок — крапки виконання програ­ми, у які вбудовуються інструкції мови, які повинні виконуватися до, після або замість строго певної крапки виконання програми. Подібні інструкції мови є функціональністю, що підтримує взає­модія компонентів. Крім того, в аспектному модулі можуть опи­суватися ролі компонентів, на які може впливати даний аспект. В окремих реалізаціях АОП за допомогою аспектних модулів мож­на впливати на існуючу схему спадкування. З погляду АОП ас­пект є сервісом, що зв' язує компоненти системи.

Для ілюстрації роботи інтегратора аспектів повернемося, на­приклад, до обробки кредитних карт. Для стислості розглянемо тільки дві операції — кредит і дебет:

public classCreditCardProcessor {

public void debit(CreditCard card, Currency amount)

throwslnvalidCardException, NotEnoughAmountException,

CardExpiredException { // логіка по дебету

}

public void credit(CreditCard card, Currency amount) throws InvalidCardException {

// логіка по кредиту

}

}

та інтерфейс журналу подій: public interface Logger { public void log(Stringmessage);

}

Для одержання бажаної композиції потрібне застосування на­ступних правил, виражених звичайною мовою:

записати в журнал початок кожної операції

записати в журнал закінчення кожної операції

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

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

public class CreditCardProcessorWithLogging { Logger _logger;

public void debit(CreditCard card, Money amount) throws InvalidCardException, NotEnoughAmountException, CardExpiredException {

_logger.log("Starting CreditCardProcessor.debit(CreditCard, Money) "+ "Card: " + card + " Amount: " + amount); // Debiting logic

_logger.log("Completing CreditCardProcessor.debit(CreditCard, Money) " + "Card: " + card + " Amount: " + amount);

}

public void credit(CreditCard card, Money amount) throws InvalidCardException { System.out.println("Debiting");

_logger.log("Starting CreditCardProcessor.credit(CreditCard, Money) " + "Card: " + card + " Amount: " + amount); // Crediting logic

_logger.log("Completing CreditCardProcessor.credit(CreditCard, Money) " + "Card: " + card + " Amount: " + amount);

}

}

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

Для підтвердження цих тез розглянемо приклад використання АОП при написанні JAVA-servlets.

Відомо, що Сервлети це високопродуктивні платформено-незалежні server-side-додатки, які написані на мові Java і склада­ють реальну конкуренцію таким технологіям, як CGI, PHP3, Perl і, звичайно, ASP.

Java-сервлети були створені в Sun. Сервлети схожі на CGI-сценарії тим, що це код, який створює документи. Проте, Сервле-ти, оскільки вони використовують Java, повинні бути скомпільо­вані перед запуском як класи, що динамічно завантажуються веб­сервером при запуску сервлетів. Інтерфейс відрізняється від CGI, JavaServer Pages або JSP; це інша технологія, що дозволяє розроб-лювачам вбудовувати Java у веб-сторінки, на зразок ASP.

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

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

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

Створимо новий аспект з pointcut, який перехоплює усі вико­нання контролерів і захоплює об' єкт запиту. Після чого на основі створеного pointcut напишемо before advice, в якості повідомлен­ня на System.out.

Код аспекту:

package aop.example;

import org.aspectj.lang.*; import javax.servlet.http.*;

// Аспект, що забезпечує аудит public aspect AuditAspect {

// Всі методи, які необхідно заносити до журналу

public pointcut controllerMethods (HttpServletRequest request) :

// Виконання усіх методів,

// параметрами яких є HttpServletRequest

// і HttpServletResponse // для всіх класів спадкоємців

HttpServlet

execution(* javax.servlet.http. HttpServlet+.*(HttpServletRequest, HttpServletResponse)) && args(request, HttpServletResponse);

* Advice який забезпечує друк на стандартний вивід

* інформації який метод буде виконано й користувача

* який виконує метод

*/

before(HttpServletRequest request) : controllerMethods(request) {

// Збираємо статичну інформацію

Signature sig = thisJoinPointStaticPart. getSignature();

// Виводимо доступну інформацію

System.out.println("User " +

request.getSession().getAttribute

(EntranceFilter.USER_KEY).toString() + " executing " + sig.

getDeclaringType().getName() +

"." + sig.getName());

}

У даному прикладі стандартний вивід системи буде відобра­жати рядки виду:

User Anonymous executing aop.example.LoginServlet.doGet User user1 executing aop.example.ViewServlet.doGet.

Як бачимо з прикладу, аспектна методологія оптимізує код Web-додатків та підвищує їх захищеність.

Таким чином, аспектно-орієнтований підхід при правильному використанні може наступне:

• зменшити обсяг коду системи (отже, знизити ймовірність програмних помилок);

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

• спростити систему завдяки локалізації коду, який не ста­виться до основної функціональності;

• спростити тестування системи (можна тестувати різні ас­пекти окремо, а тільки потім ті, що вплетені в систему). По­ліпшити керованість коду, як наслідок — простота еволюції й супроводу;

• збільшити кількість повторно використовуваних модулів зав­дяки слабкій зв' язаності підсистем.

Отже, на Web-порталах використовується багато різноманіт­них додатків і захищеність їх від атак зловмисників повинна стояти на першому місці при побудові системи захисту інфор­мації порталу. Якщо в коді додатків є «діри», які можуть вико­ристовувати потенційні нападники, то ніякі антивіруси, бранд­мауери та VPN-мережі вже не допоможуть. Отже, велику увагу захищеності додатків треба приділяти на етапі їх написання. При використанні аспектно-орієнтованого методу програму­вання спрощується код, поліпшується дизайн системи (шляхом виділення наскрізної функціональності), зменшується обсяг коду системи і ймовірність програмних помилок, які можуть завадити зловмиснику.

Література

1. Низамутдинов М.Ф. Тактика защиты и нападения на Web-приложения. СПб.: БХВ-Петербург, 2005. — 432 с.

2. I. Kiselev. Aspect-Oriented Programming with AspectJ. Indianapolis, IN, USA: SAMS Publishing, 2002.

3. J. Hannemann, G. Kiczales. Design pattern implementations in Java and AspectJ OOPSLA 02, New York, USA, November 2002. — P. 161—173.

Страницы:
1 


Похожие статьи

А В Бєгун - Аспектно-орієнтована технологія оптимізації захисту додатків web-порталу

А В Бєгун - Інформаційна парадигма безпеки економічної системи

А В Бєгун - Тендеції розвитку ринку засобів інформаційної безпеки в економіці