Разработка и реализация политики безопасности в распределенных компьютерных системах
Рассмотрены общие принципы построения и основные элементы модели политики безопасности компьютерных систем, определены потенциальные угрозы их безопасности, сформулирован и обоснован основной принцип политики безопасного администрирования. The general principles of the design and the basic elements...
Gespeichert in:
| Veröffentlicht in: | Управляющие системы и машины |
|---|---|
| Datum: | 2010 |
| Hauptverfasser: | , |
| Format: | Artikel |
| Sprache: | Russisch |
| Veröffentlicht: |
Міжнародний науково-навчальний центр інформаційних технологій і систем НАН та МОН України
2010
|
| Schlagworte: | |
| Online Zugang: | https://nasplib.isofts.kiev.ua/handle/123456789/82836 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Zitieren: | Разработка и реализация политики безопасности в распределенных компьютерных системах / В.Е. Мухин, А.М. Волокита // Управляющие системы и машины. — 2010. — № 3. — С. 78-85, 93 . — Бібліогр.: 9 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1860220325124374528 |
|---|---|
| author | Мухин, В.Е. Волокита, А.М. |
| author_facet | Мухин, В.Е. Волокита, А.М. |
| citation_txt | Разработка и реализация политики безопасности в распределенных компьютерных системах / В.Е. Мухин, А.М. Волокита // Управляющие системы и машины. — 2010. — № 3. — С. 78-85, 93 . — Бібліогр.: 9 назв. — рос. |
| collection | DSpace DC |
| container_title | Управляющие системы и машины |
| description | Рассмотрены общие принципы построения и основные элементы модели политики безопасности компьютерных систем, определены потенциальные угрозы их безопасности, сформулирован и обоснован основной принцип политики безопасного администрирования.
The general principles of the design and the basic elements of the security policy of computer systems are described. The potential threats to their security are defined, the main principles of the policy of the safe administrating is formulated and substantiated.
Розглянуто загальні принципи побудови та основні елементи моделі політики безпеки комп'ютерних систем, визначено потенційні загрози їх безпеці, сформульовано і обґрунтовано основний принцип політики безпечного адміністрування.
|
| first_indexed | 2025-12-07T18:17:37Z |
| format | Article |
| fulltext |
82 УСиМ, 2010, № 3
неинтеллектуальный терминал – при условии
защищенности линии связи между терминалом
и системой достаточно реализовать специаль-
ный протокол взаимодействия. Если же поль-
зователь работает с интеллектуальным терми-
налом, персональным компьютером или рабо-
чей станцией, задача обеспечения защищенно-
го канала связи значительно усложняется [9].
Анализ действий субъектов
Данный анализ связан с действиями субъек-
тов (событиями), относящимися к безопасности
системы. К числу таких событий относятся: вход
в систему (login); выход из системы (logout);
операции с файлами (открыть, закрыть, пере-
именовать, удалить); обращение к удаленным
ресурсам РКС; смена привилегий или других
атрибутов безопасности (прав доступа, уровня
допуска пользователя и т.п.).
Полный перечень событий в РКС, подлежа-
щих регистрации и анализу, зависит от выбора
политики безопасности и от специфики самой
РКС.
Если фиксировать все события, связанные с
безопасностью РКС, то объем регистрацион-
ной информации будет увеличиваться и эффек-
тивный анализ этих данных станет невозмож-
ным. Поэтому часто реализуется механизм вы-
борочного мониторинга как действий пользо-
вателей (например, отслеживаются только по-
дозрительные субъекты), так и событий безо-
пасности.
Мониторинг позволяет следить за пользова-
телями и реконструировать прошедшие собы-
тия, он также важен как профилактическое сред-
ство, поскольку субъекты могут воздержаться
от нарушений безопасности, зная, что их дей-
ствия фиксируются. Реконструкция событий
позволяет проанализировать случаи наруше-
ний безопасности, выяснить их причины, оце-
нить размеры ущерба и принять меры по недо-
пущению подобных нарушений в будущем.
При мониторинге событий фиксируется сле-
дующая информация:
дата и время события;
идентификатор субъекта – инициатора дей-
ствия;
тип события;
результат действия субъекта;
идентификаторы используемых объектов
(например, открываемых или удаляемых файлов);
метки безопасности субъектов и объектов
события;
изменения, внесенные в регистрационные
записи по безопасности (например, новая мет-
ка безопасности объекта).
Отметим важность не только сбора инфор-
мации, но и ее регулярного и целенаправлен-
ного анализа, т.е. гарантированности.
Гарантированность – это степень уверенно-
сти, с которой можно утверждать, что для реа-
лизации политики безопасности в РКС выбран
подходящий набор средств и что каждое из этих
средств корректно выполняет свои функции.
Выделяются два вида гарантированности –
операционная и технологическая. Операцион-
ная гарантированность относится к архитек-
турным и реализационным аспектам системы,
а технологическая – к методам построения и
сопровождения системы.
Операционная гарантированность включает
в себя проверку следующих элементов: архи-
тектура системы, целостность системы, защищен-
ность каналов передачи информации, эффектив-
ность администрирования безопасности, надеж-
ность восстановления системы после сбоев.
Операционная гарантированность позволяет
убедиться в том, что архитектура РКС и ее ре-
ализация действительно соответствует избран-
ной политике безопасности. Архитектура сис-
темы должна способствовать реализации мер бе-
зопасности и поддерживать их. Примеры по-
добных архитектурных решений в рамках ап-
паратуры и операционной системы РКС – раз-
деление команд по уровням привилегирован-
ности, защита различных процессов от взаим-
ного влияния при выделении каждому своего
виртуального пространства, особая защита яд-
ра операционной системы.
Технологическая гарантированность охва-
тывает весь жизненный цикл РКС, т.е. перио-
ды проектирования, реализации, тестирования
и сопровождения. Все перечисленные дейст-
вия должны выполняться в соответствии с ус-
тановленными требованиями, чтобы обезопа-
УСиМ, 2010, № 3 83
ситься от несанкционированного доступа к ин-
формации и нелегальных «закладок» в програм-
мное обеспечение и аппаратуру РКС.
Важный аспект технологической гарантиро-
ванности – тестирование. Тестированию подле-
жат как собственно механизмы безопасности,
так и пользовательский интерфейс к ним. Тес-
ты должны подтвердить, что защитные меха-
низмы функционируют в соответствии со сво-
им описанием и что не существует доступных
способов обхода или разрушения защиты, а так-
же продемонстрировать действенность средств
управления доступом, защищенность регистра-
ционной и аутентификационной информации.
Модель политики безопасности распреде-
ленных компьютерных систем
Рассмотрим и формализуем один из аспек-
тов политики безопасности, связанный с управ-
лением доступом субъектов к объектам РКС на
основе использования математической модели.
Фактически, рассмотрим формализацию поли-
тики безопасного администрирования РКС.
Для формализации представления модели
введем следующие обозначения:
ND = {ndi} – множество узлов РКС, которое
включает в себя сервера и рабочие станции,
SR = {sri} – подмножество серверов (маршру-
тизаторов) доменов РКС, WS = {wsi} – подмно-
жество рабочих станций, при этом: SR WS =
= ND, SR WS = .
U = {ui} – множество субъектов РКС;
A(u,ws) – функция, определяющая для субъ-
ектов {ui} множество рабочих станций {wsi}, к
которым они имеют доступ локально или по
сетевым коммуникационным каналам;
M(u,ws) – функция, определяющая для субъ-
ектов {ui} множество рабочих станций {wsi},
на которых они могут размещать и модифици-
ровать свои ресурсы: файлы, данные или про-
цессы от своего имени;
R(u,ws) – функция, определяющая множество
прав субъектов {ui} на рабочих станциях {wsi};
Rwsj – множество прав субъектов U по от-
ношению к рабочей станции wsj, таких как чи-
тать, модифицировать информацию, запускать
процессы, администрировать операционную си-
стему и т.д.
После инсталляции система безопасности
РКС характеризуется следующим образом:
множества ND, SR, WS и R (u,ws) являются
постоянными во времени. Регистрация субъек-
тов, установление их прав в системе, а также
функции серверов и рабочих станций в РКС
определяются администратором системы пе-
ред допуском субъектов к РКС;
изначально субъекты РКС не имеют сво-
их ресурсов на рабочих станциях, т.е. для каж-
дого {ui}:
M (u,ws) = ; (1)
легальный (зарегистрированный) субъект ui
рабочей станции wsj обладает правами R(ui,wsj)
по доступу к ней.
если у субъекта ui некоторые специальные
права по доступу к определенной рабочей стан-
ции wsj, например: R1 = «Отладка», R2 = «Инстал-
ляция драйверов» и т.д., то он может получить
полные права доступа Rwsj к ресурсам данной
рабочей станции, т.е:
{R1,R2,...,Rn} R(ui,wsj) ) => Rwsj . (2)
Доверенными субъектами рабочей станции
wsj являются такие субъекты ui, для которых
изначально заданы права R(ui,wsj). Множество
доверенных субъектов рабочей станции wsj обо-
значим как Uwsj. Остальные субъекты из мно-
жества U \Uwsj для данной рабочей станции яв-
ляются недоверенными.
Итак, узел nd2 непосредственно подчинен
узлу nd1, если выполняется одно из следующих
условий:
– nd1 – сервер (маршрутизатор) домена, nd2 –
рабочая станция этого домена;
– nd1 – сервер первого домена, nd2 – сервер
второго домена, который доверяет первому.
Таким образом, построим для РКС ориенти-
рованный граф подчиненности G(N, L) узлов в
РКС. В данном графе N – множество вершин
(узлов); L – множество ребер.
Всем зарегистрированным узлам (серверам
и рабочим станциям) РКС в графе G(N, L) со-
ответствует вершина, в которую входит только
одно ребро и не выходит ни одного ребра в не-
зарегистрованные узлы (вершины). Если узел
не является членом данного домена, то в графе
G(N, L) ему соответствует изолированная вер-
84 УСиМ, 2010, № 3
шина. При этом (nd1, nd2) L тогда и только
тогда, если узел nd2 непосредственно подчинен
узлу nd1, а узел nd2 подчинен узлу nd1 (nd1 →
nd2) тогда и только тогда, когда в графе G(N, L)
существует ориентированный путь от nd1 до nd2.
Покажем фрагмент графа подчиненности
G(N, L) узлов в РКС на рисунке.
Граф G(N, L) подчиненности узлов в домене РКС
В данном графе: ws1, ws2 – рабочие станции
первого домена; ws3 – рабочая станция второго
домена; ws4 – рабочая станция – не член домена;
sr1 – сервер первого домена; sr2 – сервер второго
домена, которому доверяет первый сервер. Тогда
{(sr1, ws1), (sr1, ws2), (sr2,wsЗ), (sr2, sr1)} L .
В результате, наличие у субъекта ui прав на
рабочей станции wsi определяет соответствую-
щие права на рабочих станциях, подчиненных
ей, т.е. для всех wsi → wsj :
R(ui,wsi) => R(ui,wsj) . (3)
Определим потенциальные угрозы РКС в
рамках политики безопасного администриро-
вания с использованием введенных выше па-
раметров.
Угроза 1. Если субъект ui может разместить
ресурсы на рабочей станции wsj, то существует
угроза получения им полных прав доступа к
данной рабочей станции, т.е.:
{M(ui,wsj), R(ui,wsj) ≠
≠ Rwsj } => R(ui,wsj) = Rwsj . (4)
Угроза 2. Обращение субъекта ui к ресурсам
рабочей станции wsj содержит угрозу перехва-
та его прав доступа другим субъектом ui+1, ко-
торый имеет свои ресурсы на этой рабочей
станции, т.е.:
{ А(ui,wsj): M(ui+1,wsj),
R(ui+1,wsj) ≠ Rwsj } => R(ui+1,wsj) = Rwsj . (5)
Отметим, что в РКС не все легальные субъ-
екты являются доверенными по отношению к
конкретной рабочей станции. Таким образом,
необходимо учесть, что потенциально суще-
ствует недоверенный субъект рабочей станции,
который может разместить на ней свои ресур-
сы и реализовать угрозу 2.
Сформулируем основной принцип полити-
ки безопасного администрирования РКС с ис-
пользованием введенных обозначений:
РКС удовлетворяет требованиям безопасно-
го администрирования тогда и только тогда,
когда выполняются условия 1, 2, 3 и 4.
Условие 1. При размещении субъектом ui сво-
их ресурсов на рабочей станции wsi, необхо-
димо, что бы он не имел возможности получе-
ния всех прав доступа к другой рабочей стан-
ции системы wsj, т.е.:
{M(ui,wsi), R(ui,wsi) =
= Rwsi} ≠ > R(ui,wsj) = Rwsj . (6)
Условие 2. При обращении субъекта ui к ра-
бочей станции wsi другие субъекты uj не долж-
ны получить права доступа к другой рабочей
станции wsj РКС, в том числе и к той, права
доступа к которой он имеет (wsi), т.е.:
{A(ui,wsi), R(ui,wsi) = Rwsi } ≠ >
≠ >{R(uj,wsi) = Rwsi & R(uj,wsj) = Rwsj }. (7)
Проверка условий 1 и 2 требует рассмотре-
ния всех вариантов функционирования систе-
мы, что, в общем случае, представляет собой
NP-полную задачу. Однако в практических при-
ложениях достаточно отслеживать лишь те вари-
анты, которые фактически реализуются в РКС.
Условие 3. Субъект ui имеет возможность
разместить свой ресурс на рабочей станции wsj
только в двух случаях:
данной рабочей станции не подчинена ни
одна другая рабочая станция;
субъект является доверенным субъектом
всех рабочих станций, подчиненных данной, т.е.:
{(wsj wsk), M(ui,wsj)} {(wsj → wsk),
M(ui, wsk)} = > M(ui,wsj). (8)
Условие 4. Субъект ui имеет возможность об-
ратиться к рабочей станции wsj только в том
ws4
sr2
ws3
sr1
ws1
ws2
УСиМ, 2010, № 3 85
случае, если все рабочие станции wsk, доверен-
ным субъектом которых он является, подчине-
ны данной рабочей станции, т.е.:
{(wsj → wsk), А(ui,wsk)} = > А(ui,wsj). (9)
Доказательства. Докажем необходимость
выполнения условий 1, 2, 3 и 4 для безопасно-
го администрирования РКС. Доказательство
выполним методом от противного.
Вначале докажем, что условие 1 выполняет-
ся тогда и только тогда, когда выполняется ус-
ловие 3. Докажем необходимость выполнения
условия 3 для выполнения условия 1.
Пусть существует субъект ui с правами
M(ui,wsj), для которого не выполняется условие
3, т.е. существует wsk такая, что wsk wsj, и
при wsj → wsk, субъект ui Uwsk, т.е. не имеет
прав M(ui,wsk).
Из определения угрозы 1 следует, что для
субъекта ui существует возможность получе-
ния прав R(ui,wsj) = Rwsj к рабочей станции wsj.
Из (3) следует, что при наличии у субъекта ui
прав Rwsj при условии wsj → wsk, он может по-
лучить права: R(ui,wsk) = Rwsk. Соответственно,
если субъект ui имеет права Rwsk, то как след-
ствие, он также имеет право M(ui,wsk). Таким
образом, мы пришли к противоречию, что под-
тверждает необходимость выполнения усло-
вия 3 для выполнения условия 1.
Докажем достаточность выполнения ус-
ловия 3 для выполнения условия 1.
Пусть имеются wsj, wsk, такие, что wsj wsk,
для которых не выполняется условие 1, т.е.
{M(ui,wsj), R(ui,wsj) = Rwsi} = > R (ui,wsk) = Rwsk.
Таким образом, размещение субъектом ui сво-
их ресурсов на рабочей станции wsj было ис-
пользовано им для получения всех прав на ра-
бочей станции wsk. Поскольку wsj ≠ wsk, то из
(3) следует, что это возможно лишь в случае:
wsj → wsk , т.е. рабочая станция wsj имеет в ка-
честве подчиненных все рабочие станции wsk,
что противоречит условию 3, так как субъект
ui не является доверенным субъектом всех ра-
бочих станций wsk. Таким образом, выполне-
ние условия 3 достаточно для выполнения ус-
ловия 1.
Докажем, что условие 2 выполняется тогда
и только тогда, когда выполняется условие 4.
Вначале докажем необходимость выполне-
ния условия 4 для выполнения условия 2.
Пусть существует субъект ui с правами
A(ui,wsj) по отношению к рабочей станции wsj,
для которого не выполняется условие 4, т.е.
существует рабочая станция wsk по отношению
к которой субъект ui в результате получает пра-
ва A(ui,wsk), но при этом wsj wsk .
Предположим, что существует субъект uj c
правами R(uj,wsk) = Rwsk. Тогда из условий 1 и 2,
определения угрозы 2 и (5) следует, что субъ-
ект uj имеет права M(uj,wsk), но при wsj wsk
он не может иметь прав Rwsk, т.е. R(uj,wsk) ≠ Rwsk,
что противоречит приведенному выше предпо-
ложению. Таким образом, условие 2 не выполня-
ется ввиду того, что обращение субъекта ui к ра-
бочей станции wsj не может быть использовано
субъектом uj для получения полных прав дос-
тупа на рабочей станции wsk и выполнение ус-
ловия 4 необходимо для выполнения условия 2.
Докажем достаточность выполнения ус-
ловия 4 для выполнения условия 2.
Пусть существуют субъекты ui, uj и рабочие
станции wsj, wsk такие, что wsj wsk, для кото-
рых не выполняется условие 2, т.е.: имеются
права R(ui,wsi) = Rwsj,, R(uj,wsk) = Rwsk, при этом
реализовалась угроза 2 и обращение субъекта ui
к рабочей станции wsj использовано субъектом
uj для получения всех прав доступа на рабочей
станции wsk. Но в соответствии с условиями 1
и 2 и определением угрозы 2: R(uj,wsk) Rwsk
и, следовательно, с учетом (3) в этом случае:
wsj wsk. Таким образом, полные права дос-
тупа R(uj,wsk) = Rwsk к рабочей станции wsk субъ-
ектом uj могут быть получены в результате его
простого обращения к рабочей станции wsk или
от другого недоверенного субъекта uj+1, который
несанкционированно получил соответствующие
права доступа. Но в защищенной РКС не суще-
ствует недоверенных субъектов, которые об-
ладают полными правами доступа на каком-
либо узле. Следовательно, в этом случае долж-
но выполняться условие подчиненности wsj →
→ wsk, и тогда условие 4, наоборот, не выпол-
няется, и подтверждается предположение о
том, что выполнение условия 4 достаточно
для выполнения условия 2.
Окончание на стр. 93.
УСиМ, 2010, № 3 93
тов (их порядка), количества уровней разложе-
ния сигнала, алгоритма вычисления амплитуд-
ного спектра субполосы внедрения, формата
представления численных значений и т.п.
Заключение. На основе разработанного ме-
тода в дальнейшем предполагается построение
адаптивных алгоритмов внедрения ЦВЗ, учи-
тывающих специфику реального применения, а
также получение численных оценок качества
стеганоалгоритмов в применении к аудиосиг-
налам с различными параметрами и при сжа-
тии разными кодеками с варьируемыми режи-
мом/битрейтом.
1. Грибунин В.Г., Оков И.Н., Туринцев И.В. Цифровая
стеганография. – М.: СОЛОН-Пресс, 2002. – 261 с.
2. Хорошко В.А., Шелест М.Е. Введение в компьютер-
ную стеганографию. – К.: Національний авіаційний
ун-т, 2002. – 152 с.
3. Конахович Г.Ф., Пузыренко А.Ю. Компьютерная
стеганография. – К.: МК-ПРЕСС, 2006. – 283 с.
4. Pan D.A Tutorial on MPEG/Audio Compression // IEEE
Multimedia, – 1995. – 2. – N. 2. – P. 60–74.
5. Воробьев В.И., Грибунин В.Г. Теория и практика вей-
влет-преобразования. – СПб.: Военный ун-т связи,
1999. – 203 с.
6. Лукин А. Введение в цифровую обработку сигналов
(Математические основы). – М.: МГУ, Лаборатория
компьютерной графики и мультимедиа, 2002. – 44 c.
7. Алдошина И.А. Основы психоакустики (цикл ста-
тей, Ч. 1–17) // Звукорежиссер, 1999–2002 гг. –
http://rus.625-net.ru/audioproducer/1999
Поступила 30.03.2010
Тел. для справок: (044) 526-4569 (Киев)
E-mail:k-n_v@ukr.net
© Н.В. Кошкина, 2010
Окончание статьи В.Е. Мухина и др.
Таким образом, предложенная модель позво-
ляет формально определить правила доступа
субъектов к объектам РКС, описать угрозы бе-
зопасности РКС и определить принципы и ус-
ловия безопасного администрирования РКС.
Заключение. Наличие научно-обоснованной
и формализованной политики безопасности –
обязательное условие комплексной защиты рас-
пределенных компьютерных систем.
Предложенный элемент политики безопасно-
сти – модель безопасного администрирования
доступа субъектов к объектам РКС – позволяет
формализовать важный компонент системы за-
щиты информации. Для эффективного внедре-
ния разработанной политики информационной
безопасности на основе предложенной модели
дополнительно выполняются следующие меро-
приятия: корректировка стратегии и основных
положений политики безопасности на всех ее
уровнях; постоянное совершенствование систе-
мы реагирования на инциденты; повышение эф-
фективности методов и средств аудита инфор-
мационной безопасности.
1. Шаньгин В.Ф. Информационная безопасность ком-
пьютерных систем и сетей. – М.: ФОРУМ: ИНФРА–
М, 2008. – 416 с.
2. Barman S. Writing Information Security Policies. – Bos-
ton: New Riders, 2002. – 342 p.
3. Девянин П.Н. Модели безопасности компьютерных
систем. – М.: Академия, 2005. – 143 с.
4. Галатенко В.А. Основы информационной безопас-
ности. – М.: УИТ, 2003. – 277 c.
5. ISO/IEC 27001:2005. «Information technology. Secu-
rity techniques. Information security management sys-
tems. Requirements», 18 Oct. 2005. – 44 p.
6. Peltier T.R.. Information Security Policies. Procedures
and Standards: Guideline for Effective Information
Security Management. – Boca Raton: Auerbach Publ.,
2002. – 176 p.
7. Wood C.C. Information Security Policies Made Easy. –
Houston, Texas, USA: Pentasafe Security Technolo-
gies Inc., 2002. – 84 p.
8. Application of formal methods to the analysis of web-
services security / L. Tobarra, D. Cazorle, F. Cuartero
et al. // 2nd Intern. Workshop on Web Services and For-
mal Methods (WS-FM’05), Versailles, France, Sept.
2005. – P. 215–229.
9. An Advisor for Web Services Security Policies / K. Bha-
gavan, C. Fournet, A.D. Gordon et al. // Proc. of ACM
Workshop on Secure Web Services (SWS’05), Fairfax,
Virginia, USA, Nov. 2005. – P. 197–206.
Поступила 15.01.2010
Тел. для справок: (044) 406-8650 (Киев)
E-mail: mukhin@comsys.ntu-kpi.kiev.ua, drang@ukr.net
© В.Е. Мухин, А.Н. Волокита, 2010
|
| id | nasplib_isofts_kiev_ua-123456789-82836 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 0130-5395 |
| language | Russian |
| last_indexed | 2025-12-07T18:17:37Z |
| publishDate | 2010 |
| publisher | Міжнародний науково-навчальний центр інформаційних технологій і систем НАН та МОН України |
| record_format | dspace |
| spelling | Мухин, В.Е. Волокита, А.М. 2015-06-09T20:29:29Z 2015-06-09T20:29:29Z 2010 Разработка и реализация политики безопасности в распределенных компьютерных системах / В.Е. Мухин, А.М. Волокита // Управляющие системы и машины. — 2010. — № 3. — С. 78-85, 93 . — Бібліогр.: 9 назв. — рос. 0130-5395 https://nasplib.isofts.kiev.ua/handle/123456789/82836 004.04 Рассмотрены общие принципы построения и основные элементы модели политики безопасности компьютерных систем, определены потенциальные угрозы их безопасности, сформулирован и обоснован основной принцип политики безопасного администрирования. The general principles of the design and the basic elements of the security policy of computer systems are described. The potential threats to their security are defined, the main principles of the policy of the safe administrating is formulated and substantiated. Розглянуто загальні принципи побудови та основні елементи моделі політики безпеки комп'ютерних систем, визначено потенційні загрози їх безпеці, сформульовано і обґрунтовано основний принцип політики безпечного адміністрування. ru Міжнародний науково-навчальний центр інформаційних технологій і систем НАН та МОН України Управляющие системы и машины Проблемы информационной безопасности Разработка и реализация политики безопасности в распределенных компьютерных системах The Development and Implementation of the Security Policy in Distributed Computer Systems Розробка та реалізація політики безпеки в розподілених комп’ютерних системах Article published earlier |
| spellingShingle | Разработка и реализация политики безопасности в распределенных компьютерных системах Мухин, В.Е. Волокита, А.М. Проблемы информационной безопасности |
| title | Разработка и реализация политики безопасности в распределенных компьютерных системах |
| title_alt | The Development and Implementation of the Security Policy in Distributed Computer Systems Розробка та реалізація політики безпеки в розподілених комп’ютерних системах |
| title_full | Разработка и реализация политики безопасности в распределенных компьютерных системах |
| title_fullStr | Разработка и реализация политики безопасности в распределенных компьютерных системах |
| title_full_unstemmed | Разработка и реализация политики безопасности в распределенных компьютерных системах |
| title_short | Разработка и реализация политики безопасности в распределенных компьютерных системах |
| title_sort | разработка и реализация политики безопасности в распределенных компьютерных системах |
| topic | Проблемы информационной безопасности |
| topic_facet | Проблемы информационной безопасности |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/82836 |
| work_keys_str_mv | AT muhinve razrabotkairealizaciâpolitikibezopasnostivraspredelennyhkompʹûternyhsistemah AT volokitaam razrabotkairealizaciâpolitikibezopasnostivraspredelennyhkompʹûternyhsistemah AT muhinve thedevelopmentandimplementationofthesecuritypolicyindistributedcomputersystems AT volokitaam thedevelopmentandimplementationofthesecuritypolicyindistributedcomputersystems AT muhinve rozrobkatarealízacíâpolítikibezpekivrozpodílenihkompûternihsistemah AT volokitaam rozrobkatarealízacíâpolítikibezpekivrozpodílenihkompûternihsistemah |