1c wbudowane przepełnienie stosu językowego. Przepełnienie stosu

14.04.2016 Wersja 3.22 Zmieniono interfejs, poprawiono błędy podczas przenoszenia rejestrów, zmieniono kolejność przenoszenia organizacji i polityki rachunkowości. Platforma 8.3.7.2027 BP 3.0.43.174
17.03.2016 Wersja 3.24 Naprawione błędy. Platforma 8.3.8.1747 BP 3.0.43.241
16.06.2016 Wersja 3.26 Naprawione błędy. Platforma 8.3.8.2088 BP 3.0.44.123
16.10.2016 Wersja 4.0.1.2 Naprawiono transfer przechowywania wartości, zmieniono transfer polityki rachunkowości dla wydań 3.44.*. Platforma 8.3.9.1818 BP 3.0.44.164.
19.04.2017 Wersja 4.0.2.7 Zmieniono algorytm przesyłania rejestrów związanych z katalogami, poprawiono błędy, poprawiono transfer z nadpisywaniem linków.
29.05.2017 Wersja 4.0.4.5 Zmieniono przekazywanie ruchów, dodano podgląd ruchów przeniesionych dokumentów, coś jeszcze....
30.05.2017 Wersja 4.0.4.6 Naprawiono błąd podczas uzupełniania listy katalogów istniejących w źródle (dzięki shoy)
17.06.2017 Wersja 4.0.5.1 Zmieniono algorytm przesyłania ruchu.
19.07.2017 Wersja 4.0.5.4 Zmieniono przeniesienie CI z BP 2.0. Nieoczekiwanie nastąpił transfer z Smilegm UT 10.3, w tej wersji transfer jest lekko poprawiony na tę sytuację)))
08.10.2017 Wersja 4.0.5.5 Naprawiono błędy podczas migracji z BP 2.0
19.09.2017 Wersja 4.4.5.7 Naprawiono sprawdzanie połączenia dla wersji 3.0.52.*
28.11.2017 Wersja 4.4.5.9 Naprawiono błędy
12.06.2017 Wersja 5.2.0.4 Algorytm wyszukiwania linków został przeprojektowany. Dodano procedury transferu z BP 1.6, nie ma już sztywnego wiązania z BP - można bezpiecznie używać go do przesyłania danych o "prawie" identycznych konfiguracjach. Postaram się jak najszybciej poprawić wszystkie komentarze.
12.08.2017 Wersja 5.2.1.3 Dodano algorytm przenoszenia zestawień płac z BP.2.0 do BP 3.0. Uwzględniono zmiany dotyczące udostępniania między tymi samymi konfiguracjami.
19.12.2017 Wersja 5.2.2.2 Poprawiono przenoszenie niezależnych rejestrów informacyjnych dla podręczników, które są w wymiarach tych rejestrów.

12.06.2017 Nowa wersja przetwarzania 5.2.0.4. Z istotnych zmian jest możliwość przejścia z BP 1.6 do BP 3.0. Główną zmianą jest zarządzanie wyszukiwaniem linków do katalogów - w poprzednich wersjach wyszukiwanie odbywało się po GUID, aw tej wersji można włączyć wyszukiwanie „Według szczegółów”:

17.01.2018 Wersja 5.2.2.3 Poprawiono - zauważono błędy w podrzędnych katalogach i rejestrach informacji okresowych.

19.07.2018 Wersja 5.2.2.8 Naprawione błędy.

gdzie możesz ustawić szczegóły wyszukiwania dla dowolnego katalogu. Sam ten tryb „powstał” na liczne prośby pracowników, na wypadek, gdy potrzebna jest wymiana w istniejącej już bazie danych, w której znajdują się już dane (np. aby scalić księgowość dwóch organizacji w jedną bazę).

21.12.2015 Wydano odpowiednio platformę 8.3.7.1805 i BP 3.0.43.29 oraz nową wersję przetwarzania 3.1 :-) (opis poniżej). Nowa funkcjonalność - możliwość porównania sald i obrotów pomiędzy dwiema bazami BP (dla wszystkich rachunków, jeśli plany kont są zgodne, lub dla poszczególnych kont księgowych dopasowywanych, z analityką lub bez).
01.03.2016 Wersja 3.5 - zmieniono mechanizm łączenia się z bazą źródłową - dostosowano do BSP 2.3.2.43. Naprawiono drobne błędy. Platforma 8.3.7.1845, BP 3.0.43.50
16.02.2016 Wersja 3.6 - Dodano flagę „Ustaw ręczną korektę” dla dokumentów przesyłanych z ruchami. Przeniesienie przesunięć ustalone — dokumenty z datą mniejszą niż początek okresu są przenoszone bez przesunięć. Platforma 8.3.7.1917, BP 3.0.43.116
22.03.2016 Wersja 3.10 - Dodano flagę „Zawsze przepisz linki” dla obowiązkowego przepisywania obiektów referencyjnych (prędkość transferu jest znacznie zmniejszona, ale czasami jest konieczna). Dodano zakładkę „Przygotowanie”, w której można ustawić zgodność między planem kont źródłowym i docelowym (na tym samym poziomie co kody kont) oraz przelewem stałych. Platforma 8.3.7.1970, BP 3.0.43.148

03.04.2016 Wersja 3.11 Zmieniono wypełnienie listy dokumentów istniejących w źródle: została wypełniona według ruchów zgodnie z planem kont, po prostu za pomocą linków za okres, tak jak w //site/public/ 509628/

Przetwarzanie ma na celu przesyłanie danych za dowolny okres podobny do „Upload MXL upload” z ITS, ale bez użycia plików pośrednich XML, JSON itp. – wymiana z bazy do bazy przez COM. W wersjach starszych niż 3.10 połączenie jest używane zgodnie z algorytmem z BSP, który przewiduje rejestrację comcntr.dll (jeśli system operacyjny na to „pozwala”), a także różne komunikaty, gdy nie można nawiązać połączenia , na przykład - „Infobase jest w trakcie aktualizacji” itp. . Dodano weryfikację wyboru odbiornika jako źródła bezpieczeństwa informacji - wydawane jest ostrzeżenie.

Może być używany do:

1. Transfer informacji regulacyjnych i referencyjnych (RMI) ze źródła IS do odbiornika IS (przesyłanie całego RMI odbywa się na żądanie użytkownika, niezbędne katalogi itp. są przesyłane za pośrednictwem linków podczas wszelkich transferów).

2. Przekazanie dokumentów za dowolnie wybrany okres.

3. Przeniesienie wszystkich informacji z „zepsutego” IB, jeśli jest uruchomione w trybie 1C:Enterprise, a przesłanie danych lub uruchomienie Konfiguratora nie jest możliwe.

Funkcja przetwarzania - IS odbiornika i źródła może być inny transfer od 2.0 do 3.0 - edycje są różne, ale transfer działa !!! Niedopasowane atrybuty są ignorowane lub należy dla nich określić algorytmy przesyłania.

Komentarz: Konwersja danych NIE JEST UŻYWANA! I nie pytaj dlaczego!!! Dla tych, którzy są szczególnie korodujący - BP 3.0 zmienia się prawie codziennie, nie ma siły na bieżąco aktualizować zasad transferu - tutaj wszystko jest prostsze :-).

Kolejną cechą przetwarzania jest to, że jest uruchamiane w IS odbiornika (najbliższe funkcjonalnie analogi działają na odwrót - od źródła do odbiornika).

Pierwsze kroki - musisz określić okres przetwarzania, określić organizację ze źródła, zostanie ona przekazana do miejsca docelowego.

Podczas przenoszenia organizacji przenoszona jest polityka rachunkowości oraz „towarzyszące” rejestry informacji. Dlatego przy pierwszym wybraniu organizacji w źródle minie trochę czasu, zanim pojawi się ona w odbiorniku.

Plany kont źródła i odbiorcy muszą być takie same, konta w wersji 2 nie mogą się różnić. * są przesyłane do odbiorcy, w przyszłości planowane jest włączenie ustawienia dopasowywania kont i analiz. Konta przenoszone kodami nie znajdującymi się w odbiorniku NIE SĄ TWORZONE!!!

Reszta obiektów przekazywana jest za pomocą identyfikatorów wewnętrznych (GUID), dlatego warto zwrócić uwagę na kilka kluczowych odniesień, np. Waluty.

Jeśli planujesz wymianę z "czystą" bazą danych, to lepiej przed wymianą usunąć katalogi wypełnione przy pierwszym uruchomieniu. W tym celu w przetwarzaniu udostępniana jest strona, na której można pobrać te elementy katalogów i je usunąć. Jako minimum musisz usunąć walutę „pocierać”. - ponieważ powielanie jest prawie nieuniknione (w zasadzie można to łatwo naprawić po wymianie wyszukiwania i zastąpieniu duplikatów wbudowanych w BP 3.0).

Przetwarzanie przewiduje wywołanie strony do usuwania katalogów, przy otwartym formularzu wstępnego wypełnienia:

Po otwarciu przetwarzania zostanie wyświetlona strona do usuwania katalogów wypełnionych podczas wstępnego wypełniania:

Od wersji 3.22 interfejs został zmieniony, teraz wszystkie operacje przygotowawcze są umieszczone w zakładkach i zawsze dostępne

Ważne jest, aby sprawdzić zgodność planu kont źródła i odbiorcy i koniecznie wskazać zgodność kont.

Nie musisz usuwać predefiniowanych elementów katalogu - są one przenoszone przez identyfikatory konfiguracji (nie GUID).

Możesz wybrać obiekty do przeniesienia za pomocą formularza wyboru z katalogów i dokumentów (rejestry informacyjne powiązane z tym obiektem zostaną przeniesione automatycznie, więc nie ma potrzeby ich osobnego wybierania).Przenoszenie ksiąg czasowo wyłączone - trzeba opracować spis ksiąg do przeniesienia - coś ma być przeniesione, coś nie, na tym etapie wystarczy, że jest przeniesione w księgach metrykalnych, zostanie lista ksiąg do przeniesienia w szablonie, w przyszłych wersjach.

Podczas wymiany z wersją 2.0 niektóre szczegóły (np. Informacje kontaktowe) jest przesyłany zgodnie z algorytmem wbudowanym w przetwarzanie, ponieważ dla wersji 2.0 i 3.0 są one przechowywane inaczej. Podobnie sytuacja wygląda z wieloma dokumentami (np. Korekta zadłużenia).

Lista typów obiektów może być wypełniona inaczej w wersji 3.22, jest to umieszczone w podmenu, zmiany są pokazane na rysunku:

Następuje uproszczenie obsługi przetwarzania - nie można wybierać katalogów do wymiany, a wystarczy wypełnić listę typów w odbiorniku tylko tymi typami katalogów, które mają przynajmniej jeden wpis w źródle.

Układ jest wbudowany w przetwarzanie, które zawiera listę katalogów, które nie muszą być przesyłane ze źródła do miejsca docelowego (układ „Wyklucz z przesyłania”). Możesz dodawać (usuwać) dowolne katalogi do tego układu. Jeśli nie trzeba przenosić całego NSI, wystarczy przenieść dokumenty, można również uzyskać ich listę bez wybierania typów, wystarczy wypełnić wszystkie dokumenty źródłowe, dla których istnieją transakcje.

Przesyłanie dokumentów z ruchami jest zapewnione, dla wymian 3.0 do 3.0 i zgodnie z planem kont działa jeden do jednego, przy wymianie 2.0 na 3.0 możliwe są błędy, dlatego zaleca się przesyłanie dokumentów bez ruchów, a następnie po prostu ponowne przesłanie ich w odbiornik. Podczas przesyłania dokumentów z ruchami ustawiana jest flaga „Ręczna korekta”.

Atrybut „Zaksięgowane” jest ustawiony w dokumentach odbiorcy tak samo jak w źródle, ale ruchy (jeżeli nie zostały przekazane) pojawią się dopiero po zaksięgowaniu dokumentów, np. BP 3.0 (opcja zalecana) lub z tego przetwarzania (tutaj znajduje się przycisk „Wyślij dokumenty”).

Jeżeli przetwarzanie ma służyć do trwałej wymiany, można je zarejestrować w IB odbiorcy (przycisk „Zarejestruj się”). W przypadku przelewów „jednorazowych” możesz po prostu użyć go przez Plik - Otwórz.

21.12.2015 - Wersja 3.1 platformy 8.3.7.1805 i BP 3.0.43.29 (wersja 2.15 dla 3.0.43.* nie działa - konfiguracja dość mocno się zmieniła).

Zmieniono:

Okno dialogowe wyboru opcji połączenia, flaga Klient-Serwer jest zawsze dostępna, w zależności od jej ustawienia dostępny jest wybór folderu bazy plików lub pola z nazwą bazy danych na serwerze i nazwą sam serwer (błąd w oknie dialogowym w wersji 2.15 naprawiony)

- NOWA FUNKCJONALNOŚĆ: Mechanizm uzgadniania sald i obrotów pomiędzy bazami źródłowymi i odbiorczymi w różnym stopniu szczegółowości:

Myślę, że wybór opcji pojednania jest jasny na podstawie rysunku:

Istnieją różnice w użyciu w cienkim i grubym kliencie - w grubym kliencie od razu wyświetla się okno porównania plików:

W cienkim kliencie nie zboczyłem z programowym naciskaniem przycisków, proponuję prostą opcję wyświetlania okna porównania:

Porównanie w cienkim kliencie, IMHO, jest wygodniejsze, ponieważ. ma przyciski nawigacyjne do różnic, co jest wygodniejsze w przypadku dużych ilości tabel niż przewijanie za pomocą myszy:

22.03.2016 Wersja 3.10 - Dodano flagę „Zawsze przepisz linki” dla obowiązkowego przepisywania obiektów referencyjnych (prędkość transferu jest znacznie zmniejszona, ale czasami jest konieczna). Dodano zakładkę „Przygotowanie”, w której można ustawić zgodność między planem kont źródłowym i docelowym (na tym samym poziomie co kody kont) oraz przelewem stałych. Platforma 8.3.7.1970, BP 3.0.43.148

- NOWA FUNKCJONALNOŚĆ: Przed przekazaniem dokumentów zaleca się sprawdzenie planu kont pod kątem korespondencji w miejscu źródłowym i docelowym oraz zgodności ustawionych stałych.

W tym celu dodano zakładkę „Przygotowanie”, w której można ustawić następujące korespondencje:

Algorytm wypełniania korespondencyjnej tabeli kont jest prosty - analizowane są obroty istniejące w źródle, a każdy napotkany rachunek jest wyszukiwany pod kątem dopasowania po kodzie w odbiorniku, w przypadku braku dopasowania wiersz z rachunkiem w tabeli wyświetlany jest kod, za pomocą którego należy wybrać rachunek odbiorcy, zostanie on wykorzystany przy przelewie. Dopasowywanie Pook jest ustalane na poziomie kodu.

Aby sprawdzić i przenieść zgodność ustawionych stałych, używana jest odpowiednia tabela:

W razie potrzeby uzupełniamy - przelewamy. Migrowane są tylko oznaczone stałe...

Stos programów jest specjalnym obszarem pamięci zorganizowanym zgodnie z zasadą kolejkowania LIFO (Last in, first out). Nazwa „stos” wzięła się z analogii zasady jego budowy do stosu talerzy – można układać talerze jeden na drugim (sposób dodawania do stosu „pchnięcie”, „pchnięcie”), a następnie je podnieść w górę, zaczynając od góry (sposób pobierania wartości ze stosu, „popping”, „pop”). Stos programu jest również nazywany stosem wywołań, stosem wykonawczym, stosem maszynowym (nie mylić ze „stosem” - abstrakcyjną strukturą danych).

Do czego służy stos? Pozwala w wygodny sposób zorganizować wywołanie podprogramów. Po wywołaniu funkcja otrzymuje kilka argumentów; musi też gdzieś przechowywać swoje zmienne lokalne. Ponadto musimy wziąć pod uwagę, że jedna funkcja może wywoływać inną funkcję, która również musi przekazywać parametry i przechowywać własne zmienne. Używając stosu, podczas przekazywania parametrów wystarczy umieścić je na stosie, a następnie wywoływana funkcja może je stamtąd „wyskoczyć” i użyć. Można tam również przechowywać zmienne lokalne - na początku swojego kodu funkcja przydziela część pamięci stosu, a po powrocie kontroli czyści ją i zwalnia. Programiści w językach wysokiego poziomu zwykle nie myślą o takich rzeczach - kompilator generuje dla nich cały niezbędny rutynowy kod.

Konsekwencje błędu

Teraz zbliżyliśmy się do problemu. W swojej abstrakcyjnej formie stos jest nieskończonym magazynem, do którego można dodawać nowe elementy w nieskończoność. Niestety, w naszym świecie wszystko jest skończone – a pamięć stosu nie jest wyjątkiem. Co się stanie, jeśli zakończy się, gdy argumenty funkcji zostaną umieszczone na stosie? A może funkcja przydziela pamięć dla swoich zmiennych?

Wystąpi błąd zwany przepełnieniem stosu. Ponieważ stos jest niezbędny do zorganizowania wywołania funkcji zdefiniowanych przez użytkownika (a prawie wszystkie programy we współczesnych językach, w tym zorientowane obiektowo, są zbudowane na podstawie funkcji w taki czy inny sposób), nie można ich już wywoływać. Tak więc system operacyjny przejmuje kontrolę, czyści stos i kończy działanie programu. Tu można podkreślić różnicę między przepełnieniem a stosem - w pierwszym przypadku pojawia się błąd przy dostępie do niewłaściwego obszaru pamięci, a jeśli na tym etapie nie ma zabezpieczenia, to w tym momencie się nie objawia - jeśli okoliczności są pomyślne , program może działać normalnie. Jeśli tylko pamięć, do której uzyskuje się dostęp, była chroniona, plik . W przypadku stosu program z pewnością zakończy działanie.

Aby być całkowicie dokładnym, należy zauważyć, że taki opis zdarzeń jest prawdziwy tylko dla kompilatorów, które kompilują do „natywnego” (natywnego) kodu. W językach zarządzanych maszyna wirtualna ma własny stos dla zarządzanych programów, co jest znacznie łatwiejsze do śledzenia, a nawet można sobie pozwolić na zgłoszenie wyjątku do programu w przypadku przepełnienia. W językach C i C++ nie można liczyć na taki „luksus”.

Przyczyny błędu

Co może doprowadzić do tak nieprzyjemnej sytuacji? Opierając się na mechanizmie opisanym powyżej, jedną z opcji jest zbyt wiele zagnieżdżonych wywołań funkcji. Ten scenariusz jest szczególnie prawdopodobny w przypadku korzystania z rekurencji. Nieskończona rekurencja (w przypadku braku leniwego mechanizmu oceny) pęka w ten sposób, w przeciwieństwie do , która czasami ma użyteczne zastosowanie. Jednak przy niewielkiej ilości pamięci przeznaczonej na stos (co jest np. typowe dla mikrokontrolerów) może wystarczyć prosta sekwencja wywołań.

Inną opcją są zmienne lokalne, które wymagają dużo pamięci. Uruchamianie lokalnej tablicy składającej się z miliona elementów lub miliona zmiennych lokalnych (nigdy nie wiadomo, co się stanie) nie jest najlepszym pomysłem. Nawet jedno wywołanie takiej „chciwej” funkcji może łatwo spowodować przepełnienie stosu. Aby uzyskać duże ilości danych, lepiej skorzystać z mechanizmów pamięci dynamicznej, które pozwolą przetworzyć błąd jej braku.

Jednak pamięć dynamiczna jest dość powolna jeśli chodzi o alokację i dealokację (bo zajmuje się nią system operacyjny), dodatkowo przy bezpośrednim dostępie trzeba ją alokować i zwalniać ręcznie. Pamięć na stosie jest alokowana bardzo szybko (tak naprawdę wystarczy zmienić wartość jednego rejestru), dodatkowo destruktory są automatycznie wywoływane dla obiektów alokowanych na stosie, gdy funkcja wraca i stos jest czyszczony. Oczywiście od razu pojawia się chęć zdobycia pamięci ze stosu. Dlatego trzecim sposobem na przepełnienie jest samodzielna alokacja pamięci na stosie przez programistę. Biblioteka C udostępnia specjalnie do tego celu funkcję alloca. Warto zauważyć, że jeśli funkcja malloc do przydzielania pamięci dynamicznej ma swojego „bliźniaka” do jej zwalniania, to funkcja alloca go nie ma – pamięć jest zwalniana automatycznie po zwróceniu przez funkcję kontroli. Być może to tylko komplikuje sytuację - w końcu przed wyjściem z funkcji nie będzie można zwolnić pamięci. Mimo że według strony podręcznika „funkcja alloca jest zależna od komputera i kompilatora; jej implementacja jest problematyczna i zawiera błędy w wielu systemach; jej użycie jest bardzo niepoważne i mile widziane” - nadal jest używana.

Przykłady

Jako przykład rozważmy kod rekurencyjnego wyszukiwania plików znajdujący się w witrynie MSDN:

Void DirSearch(String* sDir) (try ( // Znajdź podfoldery w przekazanym folderze. String* d = Directory::GetDirectories(sDir); int numDirs = d->get_Length(); for (int i= 0 ja< numDirs; i++) { // Find all the files in the subfolder. String* f = Directory::GetFiles(d[i],textBox1->tekst); int numFiles = f->get_Length(); dla (int j=0; j< numFiles; j++) { listBox1->Przedmioty->Dodaj(f[j]); ) DirSearch(d[i]); ) ) catch (System::Exception* e) ( MessageBox:: Show(e->Message); ) )

Ta funkcja pobiera listę plików w określonym katalogu, a następnie wywołuje samą siebie dla tych elementów listy, które okazały się katalogami. W związku z tym dla wystarczająco głębokiego drzewa system plików, otrzymamy poprawny wynik.

Przykład drugiego podejścia, zaczerpnięty z pytania „Dlaczego występuje przepełnienie stosu?” z witryny o nazwie Stack Overflow (strona ta jest zbiorem pytań i odpowiedzi na każdy temat programistyczny, a nie tylko Stack Overflow, jak mogłoby się wydawać):

#define W 1000 #define H 1000 #define MAX 100000 //... int main() ( int image; float dtr; initImg(image,dtr); return 0; )

Jak widać, w funkcji main pamięć jest alokowana na stosie dla tablic typu int i float po milion elementów każda, co w sumie daje trochę mniej niż 8 megabajtów. Biorąc pod uwagę, że domyślnie Visual C++ rezerwuje tylko 1 megabajt na stos, odpowiedź staje się oczywista.

A oto przykład zaczerpnięty z repozytorium GitHub projektu Lightspark Flash Player:

DefineSoundTag::DefineSoundTag(/* ... */) ( // ... unsigned int soundDataLength = h.getLength()-7; unsigned char *tmp = (unsigned char *)alloca(soundDataLength); // .. .)

Miejmy nadzieję, że h.getLength()-7 nie jest zbyt duży, aby następny wiersz się nie przepełnił. Ale czy czas zaoszczędzony na alokacji pamięci jest wart „potencjalnej” awarii programu?

Wynik

Przepełnienie stosu to błąd krytyczny, najczęściej popełniany przez programy zawierające funkcje rekurencyjne. Jednak nawet jeśli program nie zawiera takich funkcji, to i tak możliwe jest przepełnienie ze względu na dużą ilość zmiennych lokalnych lub błąd w ręcznym przydzielaniu pamięci na stosie. Wszystkie klasyczne zasady pozostają w mocy: jeśli jest wybór, lepiej preferować iterację zamiast rekurencji, a także nie wykonywać pracy ręcznej zamiast kompilatora.

Spis bibliograficzny

• E. Tanenbauma. Architektura komputerowa.
• Wikipedii. przepełnienie stosu.
• przepełnienie stosu. przepełnienie stosu C++.

W tym kontekście stos jest ostatnim stosem w pierwszym buforze, który przydzielasz podczas wykonywania programu. Last, First (LIFO) oznacza, że ​​ostatnia rzecz, którą wkładasz, jest zawsze pierwszą rzeczą, którą zwracasz — jeśli umieścisz 2 przedmioty na stosie, „A”, a następnie „B”, pierwszą rzeczą, którą zdejmiesz ze stosu, będzie „B”, a następną rzeczą byłoby „A”.

Kiedy wywołujesz funkcję w swoim kodzie, następna instrukcja po wywołaniu funkcji jest przechowywana na stosie i w każdym miejscu pamięci, które może zostać nadpisane przez wywołanie funkcji. Wybrana funkcja może używać więcej stosu dla swoich własnych zmiennych lokalnych. Kiedy to się skończy, zwolni miejsce na zmienną lokalną, której używał, a następnie powróci do poprzedniej funkcji.

Przepełnienie stosu

Przepełnienie stosu ma miejsce, gdy zużyłeś więcej pamięci dla stosu, niż miał zużyć twój program. W systemach wbudowanych możesz mieć tylko 256 bajtów na stos, a jeśli każda funkcja zajmuje 32 bajty, to możesz mieć tylko wywołania funkcji 8 funkcji 2 z funkcją głęboką 1, która wywołuje funkcję 3, która wywołuje funkcję 4 ... .who wywołuje funkcję 8, która wywołuje funkcję 9, ale funkcja 9 nadpisuje pamięć poza stosem. Może to nadpisać pamięć, kod itp.

Wielu programistów popełnia ten błąd, wywołując funkcję A, która następnie wywołuje funkcję B, która następnie wywołuje funkcję C, która następnie wywołuje funkcję A. Może działać przez większość czasu, ale wystarczy jedno błędne wprowadzenie spowoduje, że będzie krążyć w nieskończoność, dopóki komputer nie dowiaduje się, że stos jest pełny.

Funkcje rekurencyjne również to powodują, ale jeśli piszesz rekurencyjnie (tj.

Zwykle system operacyjny i język programowania, którego używasz, zarządza stosem i nie masz na to wpływu. Powinieneś spojrzeć na swój wykres wywołań (strukturę drzewa, która pokazuje z głównego punktu, co wywołuje każda funkcja), aby zobaczyć, jak głębokie są wywołania funkcji i zidentyfikować pętle i rekursję, które nie są zamierzone. Zamierzone pętle i rekurencja muszą być sztucznie sprawdzane pod kątem błędów, jeśli wywołują się zbyt wiele razy.

Poza dobrymi praktykami programistycznymi, testami statycznymi i dynamicznymi, w tych wysokopoziomowych systemach niewiele da się zrobić.

Systemy wbudowane

W świecie osadzonym, zwłaszcza w kodzie o wysokiej niezawodności (motoryzacja, lotnictwo, kosmos), przeprowadzasz obszerne kontrole i walidację kodu, ale wykonujesz również następujące czynności:

• Wyłącz rekursję i pętle — wymuszaj zasady i testowanie
• Trzymaj kod i stos daleko od siebie (kod we flashu, stos w pamięci RAM i nigdy nie będą pasować)
• Umieść pasma ochronne wokół stosu - pusty obszar pamięci, który wypełniasz magiczną liczbą (zwykle jest to program przerwań, ale tutaj jest wiele opcji) i setki lub tysiące razy na sekundę patrzysz na pasma ochronne, aby upewnić się, że nie zostały nadpisane.
• Używaj ochrony pamięci (tzn. nie wykonuj na stosie, nie czytaj ani nie zapisuj bezpośrednio za stosem)
• Przerwania nie wywołują funkcji drugorzędnych - ustawiają flagi, kopiują dane i pozwalają aplikacji zająć się ich przetwarzaniem (w przeciwnym razie możesz wejść głęboko w drzewo wywołań funkcji 8, mieć przerwanie, a następnie wyjść z kilku innych funkcji wewnątrz przerwanie powodujące rzut). Masz wiele drzew połączeń - jedno dla głównych procesów i jedno dla każdego przerwania. Jeśli twoje przerwania mogą sobie nawzajem przeszkadzać… cóż, są smoki…

Języki i systemy wysokiego poziomu

Ale w językach wysokiego poziomu działających w systemach operacyjnych:

• Zmniejsz przechowywanie zmiennych lokalnych (zmienne lokalne są przechowywane na stosie, chociaż kompilatory są w tym całkiem sprytne i czasami umieszczają duże fragmenty na stercie, jeśli twoje drzewo wywołań jest małe)
• Unikaj lub poważnie ograniczaj rekursję
• Nie dziel swoich programów na coraz mniejsze funkcje - nawet bez uwzględniania zmiennych lokalnych każde wywołanie funkcji zużywa do 64 bajtów na stosie (procesor 32-bitowy, oszczędność połowy rejestrów procesora, flag itp.).
• Zachowaj płytkie drzewo wywołań (podobnie jak w powyższym opisie)

Serwery WWW

To zależy od posiadanej piaskownicy, czy możesz kontrolować lub nawet widzieć stos. Są szanse, że poradzisz sobie z serwerami internetowymi, jak z każdym innym językiem wysokiego poziomu i systemem operacyjnym - to zależy od ciebie, ale sprawdź używany język i stos serwerów. Na przykład możesz rozbić stos na swoim serwerze SQL.

„Informix® DataBlade™ API Programmer's Guide” jest dostępny do pobrania pod adresem . Sekcja „Zarządzanie przestrzenią stosu” opisuje tworzenie funkcji zdefiniowanych przez użytkownika (UDR). Ten artykuł zawiera dodatkowe informacje i wskazówki dotyczące debugowania.

Poniższe informacje są ważne niezależnie od tego, czy UDR działa na zdefiniowanym przez użytkownika procesorze wirtualnym (VP), czy na procesorze VP. Stos wątku można przenieść do procesora wirtualnego zdefiniowanego przez użytkownika bezpośrednio przed wykonaniem UDR.

Jaki rozmiar stosu jest przydzielany dla UDR?

Rozmiar stosu dostępny dla UDR zależy od sposobu utworzenia UDR:

z modyfikatorem STACK, który pozwala UDR na użycie dedykowanego stosu,

bez modyfikatora STACK, co oznacza, że ​​UDR udostępni stos przydzielony serwerowi żądającemu wątkowi. Wielkość stosu w tym przypadku będzie określona przez wartość parametru STACKSIZE w pliku konfiguracyjnym onconfig.

modyfikator STOSU

Instrukcje CREATE PROCEDURE lub CREATE FUNCTION mają opcjonalny modyfikator STACK, który umożliwia określenie w bajtach ilości miejsca na stosie wymaganego do wykonania UDR.

Jeśli użyjesz modyfikatora STACK podczas tworzenia UDR, serwer przydzieli i zwolni przestrzeń stosu za każdym razem, gdy UDR zostanie wykonany. Rzeczywisty dostępny rozmiar to wartość STACK w bajtach pomniejszona o pewien narzut w zależności od liczby argumentów funkcji.

Jeśli wartość STACK jest mniejsza niż wartość parametru STACKSIZE w pliku onconfig (patrz następna sekcja), to wielkość stosu przydzielonego dla UDR zostanie automatycznie zaokrąglona w górę do wartości STACKSIZE.

parametr konfiguracyjny STACKSIZE

Plik konfiguracyjny onconfig zawiera opcję STACKSIZE, która określa domyślny rozmiar stosu dla wątków użytkownika.

Jeśli nie określisz STACK podczas tworzenia UDR, serwer nie przydzieli dodatkowego miejsca na stosie do wykonania tego UDR. Zamiast tego UDR wykorzystuje przestrzeń stosu przydzieloną do wykonania żądania. Dostępny rozmiar stosu będzie zależał od narzutu związanego z wykonywaniem funkcji na poziomie SQL.

Stos dla wątku jest przydzielany raz dla konkretnego wątku wykonującego żądanie. Wydajność jest lepsza, gdy UDR współdzieli pojedynczy stos z wątkiem, ponieważ serwer nie marnuje zasobów na przydzielanie dodatkowego stosu dla każdego wywołania UDR. Z drugiej strony, jeśli stos używany przez UDR zbliża się do STACKSIZE, może to spowodować przepełnienie stosu podczas wywoływania funkcji jako części złożonego zapytania (w takim przypadku mniej miejsca na stosie będzie dostępne do wykonania UDR).

Pamiętaj, że nie powinieneś ustawiać STACKSIZE zbyt wysoko, ponieważ wpłynie to na wszystkie wątki użytkownika.

Kiedy musisz zarządzać rozmiarem stosu?

YMusisz zarządzać miejscem na stosie, jeśli UDR wykonuje wywołania rekurencyjne lub jeśli UDR wymaga więcej miejsca na stosie, niż jest dostępne domyślnie na stosie wątku żądania (ROZMIAR STOSOWANIA).

Istnieją dwa sposoby na powiększenie stosu w celu wykonania UDR:

Określ modyfikator STACK podczas tworzenia UDR.

Użyj funkcji mi_call() do wykonywania wywołań rekurencyjnych (przykład można znaleźć w Informix DataBlade API Programmer's Guide).

Jeśli nie określisz rozmiaru za pomocą STACK i jeśli nie użyjesz mi_call() do powiększenia bieżącego stosu, a UDR zrobi coś, co wymaga dużo miejsca na stosie, spowoduje to przepełnienie stosu.

Zauważ, że niektóre funkcje, takie jak mi_*, dodają nowy segment stosu do własnego wykonania. Segmenty te są zwalniane po powrocie do wywołującego funkcję UDR.

Co zrobić, jeśli coś pójdzie nie tak?

Monitorowanie użycia stosu

Celem obserwacji jest zidentyfikowanie konkretnego UDR, który powoduje przepełnienie stosu, tak aby można było zmienić wartość STACK specjalnie dla tego konkretnego UDR.

Monitoruj użycie stosu za pomocą „onstat -g sts”

Monitoruj sesję z uruchomionym zapytaniem SQL za pomocą „onstat -g ses session_id”

Po zidentyfikowaniu zapytania SQL, które kończy się przepełnieniem stosu, należy określić użycie stosu, wykonując oddzielnie zapytania UDR, które są częścią pierwotnego zapytania.

Możesz dynamicznie ustawić wartość STACK dla UDR. Na przykład:

zmień funkcję MyFoo (lvarchar, lvarchar) za pomocą (dodaj stos = 131072);

Po zmianie wartości STACK należy przetestować pierwotne żądanie, aby upewnić się, że jest teraz stabilne.

Zwiększanie ROZMIARU STOSU

Ewentualnie spróbuj zwiększyć wartość STACKSIZE. Sprawdź, czy to rozwiązało problem. (Pamiętaj, aby później zwrócić starą wartość).

Jeśli zwiększenie STACKSIZE nie pomoże, problemem jest najprawdopodobniej uszkodzenie pamięci. Oto parę sugestii:

Włącz bazgroły pamięci i sprawdź pule pamięci. W sekcji „Problemy z debugowaniem” artykułu Alokacja pamięci dla UDRs wyjaśniono, jak to zrobić.

Rozważ ponownie użycie mi_lvarchar . Szczególną uwagę należy zwrócić na miejsca, w których przekazywany jest mi_lvarchar do funkcji, która jako argument oczekuje łańcucha zakończonego znakiem null.

Zmniejsz liczbę procesorów (lub użytkowników) VP do jednego, aby szybciej odtworzyć problem.

mi_print_stack() — Solaris

Informix Dynamic Server for OC Solaris zawiera funkcję mi_print_stack(), którą można wywołać w UDR. Domyślnie ta funkcja zapisuje ramkę stosu do następującego pliku:

/tmp/default.stack

Nie można zmienić nazwy pliku wyjściowego, ale można zmienić jego lokalizację, zmieniając wartość zmiennej środowiskowej DBTEMP. Upewnij się, że użytkownik informix ma uprawnienia do zapisu w katalogu $DBTEMP. Wszelkie błędy, które wystąpią podczas wykonywania mi_print_stack() są drukowane w $MSGPATH.

Ta funkcja jest dostępna tylko dla OC Solaris.

Słowniczek

Terminy i skróty użyte w tym artykule:

UDR	Procedura zdefiniowana przez użytkownika
wiceprezes	Wirtualny procesor

Ten artykuł po raz kolejny pokazuje, że każdy zestaw środków bezpieczeństwa powinien obejmować wszystkie etapy wdrożenia: programowanie, wdrażanie, administrowanie systemem i oczywiście środki organizacyjne. W systemach informatycznych głównym zagrożeniem bezpieczeństwa jest „czynnik ludzki” (w tym użytkownicy). Ten zestaw środków powinien być rozsądny i wyważony: nie ma sensu i jest mało prawdopodobne, że zostaną przeznaczone wystarczające środki na organizację ochrony, która przekracza koszt samych danych.

Wstęp

1C:Enterprise to najpopularniejszy system księgowy w Rosji, ale mimo to przed wersją 8.0 jego twórcy bardzo mało uwagi poświęcali kwestiom bezpieczeństwa. Zasadniczo było to oczywiście podyktowane niszą cenową produktu i koncentracją na małych firmach, w których nie ma wykwalifikowanych informatyków, a ewentualny koszt wdrożenia i utrzymania bezpiecznego systemu byłby dla przedsiębiorstwa zaporowy. Wraz z wydaniem wersji 8.0 akcenty musiały się zmienić: koszt rozwiązań znacząco wzrósł, system stał się znacznie bardziej skalowalny i elastyczny – znacząco zmieniły się wymagania. To, czy system stał się wystarczająco niezawodny i bezpieczny, jest kwestią bardzo indywidualną. Główny system informatyczny nowoczesnego przedsiębiorstwa musi spełniać co najmniej następujące wymagania bezpieczeństwa:

• Wystarczająco niskie prawdopodobieństwo awarii systemu z przyczyn wewnętrznych.
• Niezawodna autoryzacja użytkownika i ochrona danych przed błędnymi działaniami.
• Sprawny system nadawania uprawnień użytkownikom.
• System tworzenia kopii zapasowych i odzyskiwania online w przypadku awarii.

Czy rozwiązania oparte na 1C:Enterprise 8.0 spełniają te wymagania? Nie ma jednej odpowiedzi. Pomimo istotnych zmian w systemie kontroli dostępu, pozostaje wiele nierozwiązanych kwestii. W zależności od tego, jak system jest zaprojektowany i skonfigurowany, wszystkie te wymagania mogą nie być spełnione lub mogą być spełnione w stopniu wystarczającym do tego wdrożenia, jednak warto zwrócić na to uwagę (i jest to istotna konsekwencja „młodości” platformy), że aby w pełni spełnić wymienione warunki, trzeba włożyć naprawdę tytaniczny wysiłek.

Ten artykuł jest przeznaczony dla programistów i wdrożeniowców rozwiązań opartych na platformie 1C:Enterprise, a także administratorów systemów organizacji, w których używana jest 1C:Enterprise, i opisuje niektóre aspekty tworzenia i konfigurowania wersji klient-serwer systemu z punktu widzenia organizacji bezpieczeństwa informacji. Ten artykuł nie może być używany jako zamiennik dokumentacji, a jedynie wskazuje na niektóre punkty, które nie zostały jeszcze w nim odzwierciedlone. I oczywiście ani ten artykuł, ani cała dokumentacja nie będą w stanie oddać złożoności problemu budowy zabezpieczenia System informacyjny, które muszą jednocześnie spełniać sprzeczne wymagania dotyczące bezpieczeństwa, wydajności, wygody i funkcjonalności.

Klasyfikacja i terminologia

Głównym tematem rozważań w artykule są zagrożenia informacyjne.

Zagrożenie informacyjne– możliwość wystąpienia sytuacji, w której dane zostaną odczytane, skopiowane, zmodyfikowane lub zablokowane przez osoby nieupoważnione.

I na podstawie tej definicji w artykule zagrożenia informacyjne zostały sklasyfikowane w następujący sposób:

• Nieautoryzowane zniszczenie danych
• Nieautoryzowana modyfikacja danych
• Nieautoryzowane kopiowanie danych
• Nieautoryzowany odczyt danych
• Niedostępność danych

Wszystkie zagrożenia dzielą się na umyślne i niezamierzone. Zrealizowane zagrożenie informacyjne zostanie nazwane incydent. Cechy systemu to:

Luki w zabezpieczeniach– cechy prowadzące do incydentów Środki ochronne– cechy blokujące możliwość wystąpienia incydentu

Zasadniczo brane są pod uwagę tylko te przypadki, których prawdopodobieństwo wynika z zastosowania platformy technologicznej 1C:Enterprise 8.0 w wersji klient-serwer (dalej, w przypadkach, gdy nie jest to sprzeczne ze znaczeniem po prostu 1C lub 1C 8.0) . Definiujemy następujące główne role w odniesieniu do korzystania z systemu:

• Operatorzy– użytkownicy, którzy mają ograniczone uprawnienia roli aplikacji do przeglądania i modyfikowania danych, ale nie mają funkcji administracyjnych
• Administratorzy systemu– użytkowników posiadających uprawnienia administracyjne w systemie, w tym uprawnienia administracyjne w systemach operacyjnych serwera aplikacji i serwera MS SQL, uprawnienia administracyjne w MS SQL itp.
• Administratorzy bezpieczeństwa informacji- użytkownicy, którym oddelegowano określone funkcje administracyjne w bazie danych 1C (takie jak dodawanie użytkowników, testowanie i naprawianie, tworzenie kopii zapasowych, konfigurowanie rozwiązania aplikacyjnego itp.)
• Deweloperzy systemów- użytkownicy, którzy opracowują rozwiązanie aplikacyjne. Ogólnie rzecz biorąc, mogą nie mieć dostępu do działającego systemu.
• Osoby bez bezpośredniego dostępu do systemu- użytkownicy, którym nie delegowano praw dostępu do 1C, ale którzy mogą w mniejszym lub większym stopniu wpływać na działanie systemu (zwykle są to wszyscy użytkownicy tej samej domeny Active Directory, w której jest zainstalowany system). Ta kategoria jest brana pod uwagę przede wszystkim w celu identyfikacji potencjalnie niebezpiecznych podmiotów w systemie.
• Automatyczne skrypty administracyjne– programy, którym delegowane są określone funkcje, przeznaczone do automatycznego wykonywania określonych czynności (np. import-eksport danych)

W tym miejscu należy zwrócić uwagę na dwie kwestie: po pierwsze klasyfikacja ta jest bardzo przybliżona i nie uwzględnia podziałów w ramach każdej z grup – taki podział będzie tworzony dla konkretnych przypadków, a po drugie zakłada się, że inne osoby nie mogą wpływać na działanie system, który powinien być zapewniony za pomocą środków zewnętrznych w stosunku do 1C.

Każdy system bezpieczeństwa musi być zaprojektowany z myślą o wykonalności i kosztach posiadania. Ogólnie rzecz biorąc, przy tworzeniu i wdrażaniu systemu informatycznego konieczne jest, aby cena ochrony systemu odpowiadała:

• wartość chronionych informacji;
• koszt wywołania incydentu (w przypadku celowego zagrożenia);
• ryzyko finansowe w przypadku incydentu

Bezsensowne i szkodliwe jest organizowanie ochrony dużo droższej niż ocena jej efektywności finansowej. Istnieje kilka metod oceny ryzyka utraty informacji, ale nie zostały one omówione w tym artykule. Innym ważnym aspektem jest zachowanie równowagi często sprzecznych wymagań dotyczących bezpieczeństwa informacji, wydajności systemu, wygody i łatwości użytkowania systemu, szybkości rozwoju i wdrażania oraz innych wymagań dla systemów informatycznych przedsiębiorstwa.

Główne cechy mechanizmu bezpieczeństwa informacji systemu

1C:Enterprise 8.0 występuje w dwóch wersjach: plikowej i klient-serwer. Wersja pliku nie może być uznana za zapewniającą bezpieczeństwo informacji systemu z następujących powodów:

• Dane i konfiguracja są przechowywane w pliku, który jest dostępny do odczytu i zapisu dla wszystkich użytkowników systemu.
• Jak zostanie pokazane poniżej, autoryzację systemu można bardzo łatwo ominąć.
• Integralność systemu zapewnia tylko rdzeń części klienckiej.

W wersji klient-serwer MS SQL Server służy do przechowywania informacji, co zapewnia:

• Bezpieczniejsze przechowywanie danych.
• Odizoluj pliki od bezpośredniego dostępu.
• Bardziej zaawansowane mechanizmy transakcyjne i blokujące.

Pomimo znacznych różnic pomiędzy wersją plikową i klient-serwer systemu, posiadają one jeden schemat kontroli dostępu na poziomie rozwiązania aplikacyjnego, który zapewnia następujące funkcjonalności:

• Autoryzacja użytkownika za pomocą hasła określonego w 1C.
• Autoryzacja użytkownika przez bieżącego użytkownika systemu Windows.
• Przypisywanie ról użytkownikom systemu.
• Ograniczenie wykonywania funkcji administracyjnych według ról.
• Przypisanie dostępnych interfejsów według ról.
• Ograniczanie dostępu do obiektów metadanych według ról.
• Ograniczanie dostępu do szczegółów obiektów według ról.
• Ograniczanie dostępu do obiektów danych według ról i parametrów sesji.
• Ograniczenie interaktywnego dostępu do danych i modułów wykonywalnych.
• Niektóre ograniczenia wykonania kodu.

Generalnie zastosowany schemat dostępu do danych jest dość typowy dla systemów informatycznych tego poziomu. Jednak w odniesieniu do tej implementacji trójwarstwowej architektury klient-serwer istnieje kilka fundamentalnych aspektów, które prowadzą do stosunkowo dużej liczby luk w zabezpieczeniach:

1. Duża liczba etapów przetwarzania danych, a na każdym etapie mogą obowiązywać inne zasady dostępu do obiektów.

   Nieco uproszczony schemat etapów przetwarzania danych istotnych z punktu widzenia bezpieczeństwa przedstawiono na rys. 1. Ogólną zasadą dla 1C jest zmniejszanie ograniczeń w miarę przechodzenia w dół tego schematu, dlatego wykorzystanie luki w jednym z wyższe poziomy może zakłócić system na wszystkich poziomach.

2. Niewystarczająco debugowane procedury kontrolowania przesyłanych danych podczas przechodzenia z poziomu na poziom.

   Niestety nie wszystkie wewnętrzne mechanizmy systemu są idealnie debugowane, szczególnie w przypadku mechanizmów nieinteraktywnych, których debugowanie jest zawsze z jednej strony bardziej czasochłonne, ale z drugiej bardziej odpowiedzialne. Ta „choroba” nie jest problemem wyłącznie 1C, występuje w wielu produktach serwerowych większości dostawców. Dopiero w ostatnich latach znacznie wzrosło zainteresowanie tymi problemami.

3. Niewystarczająco wysokie średnie kwalifikacje programistów i administratorów systemu, odziedziczone po poprzedniej wersji.

   Produkty linii 1C:Enterprise pierwotnie koncentrowały się na łatwości rozwoju i wsparcia oraz pracy w małych organizacjach, więc nie jest zaskakujące, że historycznie znaczna część „twórców” zastosowanych rozwiązań i „administratorów” systemów nie posiadać wystarczającą wiedzę i umiejętności do pracy z dużo bardziej złożonym produktem, jakim jest wersja 8.0. Problem pogłębia przyjęta w firmach franczyzowych praktyka trenowania „w boju” kosztem klientów, bez systematycznego podejścia do tej kwestii. Trzeba przyznać 1C, że w ciągu ostatnich kilku lat sytuacja ta stopniowo się poprawiała: poważni franczyzobiorcy stali się bardziej odpowiedzialni w swoim podejściu do problemu rekrutacji i szkolenia personelu, poziom wsparcia informatycznego od 1C znacznie wzrosła, pojawiły się programy certyfikacji ukierunkowane na wysoki poziom usług; ale sytuacji nie da się naprawić od razu, więc ten czynnik powinien być brany pod uwagę przy analizie bezpieczeństwa systemu.

4. Stosunkowo mały wiek platformy.

   Wśród produktów o podobnym ukierunkowaniu i przeznaczeniu jest to jedno z najmłodszych rozwiązań. Funkcjonalność platformy mniej więcej ustabilizowała się niecały rok temu. Jednocześnie każde kolejne wydanie platformy, począwszy od 8.0.10 (to właśnie w tym wydaniu zaimplementowano prawie wszystkie dotychczasowe funkcje systemu) stawało się znacznie stabilniejsze niż poprzednie. Funkcjonalność stosowanych standardowo rozwiązań wciąż rośnie w zawrotnym tempie, choć wykorzystywana jest tylko połowa możliwości platformy. Oczywiście w takich warunkach mówienie o stabilności może być dość arbitralne, ale ogólnie trzeba przyznać, że pod wieloma względami rozwiązania oparte na platformie 1C 8.0 znacznie wyprzedzają pod względem funkcjonalności i wydajności (i często pod względem stabilność) podobne rozwiązania na platformie 1C 7.7.

Tak więc system (i ewentualnie typowe rozwiązanie aplikacyjne) jest wdrażany w przedsiębiorstwie i instalowany na komputerach. Przede wszystkim konieczne jest stworzenie środowiska, w którym ustawienie bezpieczeństwa 1C będzie miało sens, a do tego musi być skonfigurowane w taki sposób, aby spełnione zostało założenie, że ustawienia systemowe znacząco wpływają na bezpieczeństwo systemu.

Postępuj zgodnie z ogólnymi zasadami konfigurowania zabezpieczeń.

Nie może być mowy o jakimkolwiek bezpieczeństwie informacyjnym systemu, jeżeli nie są przestrzegane podstawowe zasady tworzenia bezpiecznych systemów. Upewnij się, że spełnione są co najmniej następujące warunki:

• Dostęp do serwerów jest fizycznie ograniczony i zapewniona jest ich nieprzerwana praca:
  • sprzęt serwerowy spełnia wymagania dotyczące niezawodności, debugowano wymianę wadliwego sprzętu serwerowego, stosowane są schematy z powielaniem sprzętu dla szczególnie krytycznych obszarów (RAID, zasilanie z kilku źródeł, kilka kanałów komunikacyjnych itp.);
  • serwery znajdują się w pomieszczeniu zamkniętym, a pomieszczenie to jest otwierane tylko na czas pracy, której nie można wykonać zdalnie;
  • prawo otwierania serwerowni ma tylko jedna lub dwie osoby, w nagłych przypadkach opracowano system powiadamiania osób odpowiedzialnych;
  • zapewnia nieprzerwane zasilanie serwerów
  • zapewniony jest normalny tryb klimatyczny działania sprzętu;
  • w serwerowni jest alarm przeciwpożarowy, nie ma możliwości zalania (szczególnie pierwszego i ostatniego piętra);
• Ustawienia sieci i infrastruktury informatycznej przedsiębiorstwa są prawidłowe:
  • firewalle są zainstalowane i skonfigurowane na wszystkich serwerach;
  • wszyscy użytkownicy i komputery są autoryzowani w sieci, hasła są na tyle złożone, że nie można ich odgadnąć;
  • operatorzy systemu mają wystarczające uprawnienia do normalnej pracy z nim, ale nie mają uprawnień do działań administracyjnych;
  • wszystkie komputery w sieci mają zainstalowane i włączone narzędzia antywirusowe;
  • pożądane jest, aby użytkownicy (z wyjątkiem administratorów sieci) nie posiadali uprawnień administracyjnych na klienckich stacjach roboczych;
  • dostęp do internetu i przenośnych nośników informacji powinien być regulowany i ograniczany;
  • należy skonfigurować audyt systemowy zdarzeń związanych z bezpieczeństwem;
• Główne problemy organizacyjne zostały rozwiązane:
  • użytkownicy mają kwalifikacje do pracy z 1C i sprzętem;
  • informowanie użytkowników o odpowiedzialności za naruszenie zasad działania;
  • ponosi odpowiedzialność finansową za każdy istotny element systemu informatycznego;
  • wszystkie bloki systemu są uszczelnione i zamknięte;
  • zwrócić szczególną uwagę na instrukcje i nadzór osób sprzątających pomieszczenia, budowniczych i elektryków. Osoby te mogą nieumyślnie wyrządzić szkodę nieporównywalną z umyślną szkodą spowodowaną przez pozbawionego skrupułów użytkownika systemu.

Uwaga! Ta lista nie jest wyczerpująca, ale opisuje tylko to, co jest często pomijane podczas wdrażania dość złożonego i kosztownego systemu informatycznego!

• MS SQL Server, serwer aplikacyjny i część kliencka działają na różnych komputerach, aplikacje serwerowe działają na prawach specjalnie utworzonych użytkowników Windows;
• Dla serwera MS SQL
  • ustawiony tryb autoryzacji mieszanej
  • Użytkownicy MS SQL objęci rolą serveradmin nie uczestniczą w 1C,
  • dla każdego IB 1C utworzony został osobny użytkownik MS SQL, który nie posiada uprzywilejowanego dostępu do serwera,
  • Użytkownik MS SQL jednego IB nie ma dostępu do innych IB;
• Użytkownicy nie mają bezpośredniego dostępu do plików serwera aplikacji i serwera MS SQL
• Stanowiska operatorskie wyposażone są w system Windows 2000/XP (nie Windows 95/98/Me)

Nie zaniedbuj zaleceń twórców systemu i czytania dokumentacji. Na dyskach ITS w dziale „Wytyczne” publikowane są ważne materiały dotyczące konfiguracji systemu. Zwróć szczególną uwagę na następujące artykuły:

1. Funkcje pracy aplikacji z serwerem 1C: Enterprise
2. Umieszczenie danych 1C:Enterprise 8.0
3. Aktualizacja 1C: Enterprise 8.0 przez użytkowników Microsoft Windows bez uprawnień administratora
4. Edycja listy użytkowników w imieniu użytkownika, który nie posiada uprawnień administracyjnych
5. Konfigurowanie ustawień zapory systemu Windows XP z dodatkiem SP2 dla programu SQL Server 2000 i SQL Server Desktop Engine (MSDE)
6. Konfigurowanie parametrów COM+ Windows XP SP2 dla działania serwera 1C:Enterprise 8.0
7. Konfigurowanie ustawień zapory systemu Windows XP SP2 dla działania serwera 1C:Enterprise 8.0
8. Konfigurowanie ustawień zapory systemu Windows XP z dodatkiem SP2 dla Menedżera licencji HASP
9. Utwórz kopię zapasową baza informacji przy użyciu SQL Servera 2000
10. Problemy z instalacją i konfiguracją 1C: Enterprise 8.0 w wersji „klient-serwer”.(jeden z ważniejszych artykułów)
11. Osobliwości ustawienia okien Server 2003 podczas instalowania serwera 1C:Enterprise 8.0
12. Regulacja dostępu użytkowników do infobazy w wersji klient-serwer(jeden z ważniejszych artykułów)
13. Serwer 1C: Enterprise i SQL Server
14. Szczegółowa procedura instalacji 1C:Enterprise 8.0 w wersji „klient-serwer”.(jeden z ważniejszych artykułów)
15. Korzystanie z wbudowanego języka na serwerze 1C:Enterprise

Ale czytając dokumentację, krytycznie podchodź do otrzymanych informacji, na przykład w artykule „Problemy z instalacją i konfiguracją 1C: Enterprise 8.0 w wersji „klient-serwer”” prawa wymagane dla użytkownika USER1CV8SERVER nie są dość dokładnie opisane. Będą linki do poniższej listy, na przykład [ITS1] oznacza artykuł „Osobliwości działania aplikacji z serwerem 1C:Enterprise”. Wszystkie odniesienia do artykułów odnoszą się do najnowszego wydania ITS w momencie pisania (styczeń 2006)

Korzystaj z możliwości autoryzacji dla użytkowników w połączeniu z autoryzacją Windows

Spośród dwóch możliwych trybów autoryzacji użytkownika: wbudowany 1C i połączony z autoryzacją systemu operacyjnego Windows, jeśli to możliwe, należy wybrać autoryzację połączoną. Pozwoli to nie mylić użytkowników z kilkoma hasłami w pracy, ale jednocześnie nie obniży poziomu bezpieczeństwa systemu. Jednak nawet dla użytkowników korzystających tylko z autoryzacji Windows bardzo pożądane jest ustawienie hasła podczas tworzenia, a dopiero potem wyłączenie autoryzacji 1C dla tego użytkownika. Aby zapewnić przywrócenie systemu w przypadku zniszczenia struktury Active Directory, konieczne jest pozostawienie co najmniej jednego użytkownika, który może zalogować się przy użyciu autoryzacji 1C.

Podczas tworzenia ról rozwiązania aplikacyjnego nie dodawaj uprawnień „zapasowych”.

Każda rola rozwiązania aplikacyjnego powinna odzwierciedlać minimalny wymagany zestaw uprawnień do wykonywania działań zdefiniowanych przez tę rolę. Jednak niektórych ról nie można używać niezależnie. Na przykład, aby interaktywnie uruchomić obróbka zewnętrzna możesz utworzyć oddzielną rolę i dodać ją do wszystkich użytkowników, którzy powinni korzystać z przetwarzania zewnętrznego.

Regularnie przeglądaj dzienniki systemowe i dzienniki

W miarę możliwości reguluj i automatyzuj przeglądanie logów i protokołów z pracy systemu. Przy odpowiedniej konfiguracji i regularnym przeglądaniu logów (przefiltrowanych tylko po ważnych zdarzeniach) można na czas wykrywać nieautoryzowane działania, a nawet zapobiegać im na etapie przygotowań.

Niektóre funkcje wersji klient-serwer

W tej sekcji opisano niektóre funkcje wersji klient-serwer i ich wpływ na bezpieczeństwo. Dla ułatwienia czytania przyjęto następującą notację:

Uwaga! opis podatności

Przechowywanie informacji kontrolujących dostęp do systemu

Przechowywanie listy użytkowników IB

Wszystkie informacje o liście użytkowników tego IS i dostępnych dla nich rolach są przechowywane w tabeli Params w bazie danych MS SQL (patrz [ITS2]). Patrząc na strukturę i zawartość tej tabeli staje się oczywiste, że wszystkie informacje o użytkownikach są przechowywane w rekordzie o wartości pola FileName - "users.usr".

Ponieważ zakładamy, że użytkownicy nie mają dostępu do bazy MS SQL, fakt ten sam w sobie nie może zostać wykorzystany przez atakującego, jednak jeśli możliwe jest wykonanie kodu w MS SQL, to „otwiera to drzwi” do uzyskania dowolnego (! ) dostęp z 1C . Ten sam mechanizm (z niewielkimi zmianami) można zastosować do wersji plikowej systemu, co biorąc pod uwagę specyfikę wersji plikowej, całkowicie wyklucza jego zastosowanie w budowaniu bezpiecznych systemów.

Rekomendacje: Obecnie nie ma możliwości całkowitego zabezpieczenia aplikacji przed taką zmianą, poza wykorzystaniem wyzwalaczy na poziomie MS SQL Server, co z kolei może powodować problemy przy aktualizacji wersji platformy czy zmianie listy użytkowników. Aby śledzić takie zmiany, możesz użyć dziennika 1C (zwracając uwagę na „podejrzane” logowania w trybie konfiguratora bez określania użytkownika) lub utrzymywać ciągłe działanie programu SQL Profiler (co będzie miało bardzo negatywny wpływ na wydajność systemu) lub skonfigurować alerty mechanizm (najprawdopodobniej razem za pomocą wyzwalaczy)

Przechowywanie informacji o liście IB na serwerze

Dla każdego serwera aplikacji 1C informacje są przechowywane na liście podłączonych do niego baz danych MS SQL. Każda baza danych używa własnego ciągu połączenia między serwerem aplikacji a serwerem MS SQL. Informacje o bazach danych zarejestrowanych na serwerze aplikacji wraz z ciągami połączeń są przechowywane w pliku srvrib.lst, który znajduje się na serwerze w katalogu<Общие данные приложений>/1C/1Cv8 (na przykład C:/Documents and Settings/All Users/Application Data/1C/1Cv8/srvrib.lst). Dla każdego IB przechowywany jest kompletny ciąg połączenia, w tym hasło użytkownika MS SQL w przypadku korzystania z mieszanego modelu autoryzacji MS SQL. To właśnie obecność tego pliku pozwala bać się nieautoryzowanego dostępu do bazy danych MS SQL, a jeśli wbrew zaleceniom do dostępu do co najmniej jednej bazy zostanie użyty użytkownik uprzywilejowany (np. „sa”) , to oprócz zagrożenia ze strony jednego IS istnieje zagrożenie dla całego systemu korzystającego z MS SQL.

Warto zauważyć, że użycie autoryzacji mieszanej i autoryzacji Windows na serwerze MS SQL prowadzi do różnego rodzaju problemów podczas uzyskiwania dostępu do tego pliku. Tak więc kluczowymi negatywnymi właściwościami autoryzacji systemu Windows będą:

• Praca całego zabezpieczenia informacji na serwerze aplikacyjnym oraz na serwerze MS SQL w ramach jednego zestawu uprawnień (najprawdopodobniej redundantne)
• Z procesu serwera aplikacji 1C (lub w ogólnym przypadku od użytkownika USER1CV8SERVER lub jego odpowiednika) bez podawania hasła można łatwo połączyć się z dowolnymi zabezpieczeniami informacji bez podawania hasła

Z drugiej strony uzyskanie możliwości wykonania dowolnego kodu z kontekstu użytkownika USER1CV8SERVER może być dla atakującego trudniejsze niż uzyskanie określonego pliku. Nawiasem mówiąc, obecność takiego pliku jest kolejnym argumentem przemawiającym za rozłożeniem funkcji serwera na różne komputery.

Rekomendacje: Plik srvrib.lst powinien być dostępny tylko dla procesu serwera. Pamiętaj, aby skonfigurować inspekcję, aby zmienić ten plik.

Niestety domyślne dany plik prawie nie jest chroniony przed odczytem, ​​co należy wziąć pod uwagę podczas wdrażania systemu. Idealnie byłoby, gdyby serwer aplikacji uniemożliwiał odczyt i zapis tego pliku (w tym odczyt i zapis przez połączenia użytkownika wykonywane na tym serwerze) w czasie wykonywania.

Brak autoryzacji przy tworzeniu IB na serwerze

Uwaga! Błąd braku autoryzacji został naprawiony w wydaniu 8.0.14 platformy 1C:Enterprise. W tej wersji pojawiła się koncepcja „1C:Enterprise Server Administrator”, ale dopóki lista administratorów jest określona na serwerze, system działa w sposób opisany poniżej, więc nie zapomnij o tej możliwej funkcji.

Prawdopodobnie największą luką w tej sekcji jest możliwość niemal nieograniczonego dodawania zabezpieczeń informacji do serwera aplikacji, w wyniku czego każdy użytkownik, który uzyskał dostęp do połączenia z serwerem aplikacji, automatycznie otrzymuje możliwość uruchomienia dowolnego kodu na aplikacji serwer. Spójrzmy na to na przykładzie.

System należy zainstalować w następującej wersji

• MS SQL Server 2000 (na przykład nazwa sieci SRV1)
• Serwer 1C: Enterprise 8.0 (nazwa sieci SRV2)
• Strona klienta 1C:Enterprise 8.0 (nazwa sieci WS)

Przyjmuje się, że użytkownik (dalej UŻYTKOWNIK) pracujący na WS ma co najmniej minimalny dostęp do jednego z IB zarejestrowanych na SRV2, ale nie ma uprzywilejowanego dostępu do SRV1 i SRV2. Ogólnie rzecz biorąc, połączenie funkcji przez wymienione komputery nie ma wpływu na sytuację. System został skonfigurowany z uwzględnieniem zaleceń zawartych w dokumentacji oraz na dyskach ITS. Sytuacja jest pokazana na rys. 2.

• skonfigurować zabezpieczenia COM+ na serwerze aplikacji, aby tylko użytkownicy 1C mieli prawo łączenia się z procesem serwera aplikacji (więcej szczegółów [ITS12]);
• plik srvrib.lst musi być tylko do odczytu dla użytkownika USER1CV8SERVER (aby dodać nowy IB do serwera, tymczasowo zezwól na zapis);
• aby połączyć się z MS SQL, użyj tylko protokołu TCP / IP, w tym przypadku możesz:
  • ogranicz połączenia za pomocą zapory ogniowej;
  • skonfiguruj użycie niestandardowego portu TCP, co skomplikuje połączenie „obcego” IB 1C;
  • stosować szyfrowanie przesyłanych danych pomiędzy serwerem aplikacji a serwerem SQL;
• skonfigurować zaporę serwera w taki sposób, aby uniemożliwić korzystanie z serwerów MS SQL firm trzecich;
• korzystać z narzędzi bezpieczeństwa intranetu, aby wykluczyć możliwość pojawienia się nieautoryzowanego komputera w sieci lokalnej (IPSec, polityki bezpieczeństwa grup, zapory ogniowe itp.);
• w żadnym wypadku nie nadawać uprawnień administracyjnych użytkownikowi USER1CV8SERVER na serwerze aplikacji.

Używanie kodu działającego na serwerze

Korzystając z wersji 1C klient-serwer, programista może rozdzielać wykonywanie kodu między klientem a serwerem aplikacji. Aby kod (procedura lub funkcja) mógł być wykonywany tylko na serwerze, konieczne jest umieszczenie go we wspólnym module, dla którego ustawiona jest właściwość „Serwer”, a w przypadku, gdy wykonanie modułu jest dozwolone nie tylko na serwerze, umieść kod w sekcji zastrzeżonej „#If Server”:

#Jeśli serwer to
Funkcja OnServer(Param1, Param2 = 0) Export // Ta funkcja mimo swojej prostoty jest wykonywana na serwerze
Param1 = Param1 + 12;
Zwróć parametr1;
Funkcje końcowe
#KoniecJeśli

Używając kodu działającego na serwerze, pamiętaj, że:

• kod jest wykonywany z uprawnieniami USER1CV8SERVER na serwerze aplikacji (dostępne są obiekty COM i pliki serwera);
• wszystkie sesje użytkowników są uruchamiane przez jedną instancję usługi, więc np. przepełnienie stosu na serwerze spowoduje rozłączenie wszystkich aktywnych użytkowników;
• debugowanie modułów serwera jest trudne (na przykład nie można ustawić punktu przerwania w debugerze), ale powinno być wykonane;
• przekazanie sterowania z klienta do serwera aplikacji i odwrotnie może wymagać znacznych zasobów przy dużej ilości przesyłanych parametrów;
• korzystanie z narzędzi interaktywnych (formularze, arkusze kalkulacyjne, okna dialogowe), zewnętrzne raporty i przetwarzanie w kodzie na serwerze aplikacji nie jest możliwe;
• niedozwolone jest stosowanie zmiennych globalnych (zmiennych modułów aplikacji zadeklarowanych opcją „Eksportuj”);

Zobacz [ITS15] i inne artykuły ITS, aby uzyskać szczegółowe informacje.

Serwer aplikacji musi spełniać specjalne wymagania dotyczące niezawodności. W poprawnie zbudowanym systemie klient-serwer muszą być spełnione następujące warunki:

• żadne działania aplikacji klienckiej nie powinny przerywać działania serwera (poza przypadkami administracyjnymi);
• serwer nie może wykonać kodu programu otrzymanego od klienta;
• zasoby powinny być „sprawiedliwie” rozdzielone połączenia klienckie, zapewniając dostępność serwera niezależnie od aktualnego obciążenia;
• w przypadku braku blokad danych połączenia klientów nie powinny wpływać na wzajemną pracę;
• nie na serwerze interfejs użytkownika, ale należy opracować narzędzia monitorowania i rejestrowania;

Ogólnie rzecz biorąc, system 1C jest zbudowany w taki sposób, aby zbliżyć się do tych wymagań (na przykład nie można wymusić zewnętrznego przetwarzania na serwerze), ale nadal istnieje kilka nieprzyjemnych funkcji, dlatego:

Rekomendacje: Przy projektowaniu wykonania back-endowego zaleca się przestrzeganie zasady minimalnego interfejsu. Te. liczba wejść do modułów serwera z aplikacji klienckiej powinna być bardzo ograniczona, a parametry ściśle regulowane. Rekomendacje: Przy odbiorze parametrów procedur i funkcji na serwer konieczne jest wykonanie walidacji parametrów (sprawdzenie, czy parametry odpowiadają oczekiwanemu typowi i zakresowi wartości). W standardowych rozwiązaniach tego nie robi się, ale bardzo pożądane jest wprowadzenie obowiązkowej walidacji we własnych opracowaniach. Rekomendacje: Podczas generowania tekstu żądań (a tym bardziej parametru polecenia Uruchom) po stronie serwera nie należy korzystać z ciągów otrzymanych z aplikacji klienckiej.

Ogólnym zaleceniem byłoby zapoznanie się z zasadami bezpiecznego budowania sieć-aplikacje do baz danych i praca na podobnych zasadach. Podobieństwo jest naprawdę znaczne: po pierwsze, podobnie jak aplikacja internetowa, serwer aplikacji jest warstwą pośrednią między bazą danych a interfejsem użytkownika (główna różnica polega na tym, że serwer WWW tworzy interfejs użytkownika); po drugie, z punktu widzenia bezpieczeństwa, nie można ufać danym otrzymanym od klienta, ponieważ możliwe jest uruchamianie zewnętrznych raportów i przetwarzania.

Przekazywanie parametrów

Przekazywanie parametrów do funkcji (procedury) uruchomionej na serwerze to dość delikatna kwestia. Wynika to przede wszystkim z konieczności przesyłania ich pomiędzy procesem serwera aplikacji a klientem. Gdy sterowanie jest przekazywane ze strony klienta na stronę serwera, wszystkie przesyłane parametry są serializowane, przekazywane na serwer, gdzie są „rozpakowywane” i wykorzystywane. Podczas przechodzenia ze strony serwera na stronę klienta proces jest odwrotny. Należy tutaj zauważyć, że ten schemat poprawnie obsługuje przekazywanie parametrów przez referencję i wartość. Podczas przekazywania parametrów obowiązują następujące ograniczenia:

• Między klientem a serwerem (w obu kierunkach) mogą być przesyłane tylko niezmienne wartości (tj. których wartości nie można zmienić): typy pierwotne, referencje, kolekcje generyczne, systemowe wartości wyliczeniowe, przechowywanie wartości. Jeśli spróbujesz wysłać coś innego, aplikacja kliencka ulegnie awarii (nawet jeśli serwer spróbuje wysłać nieprawidłowy parametr).
• Nie zaleca się przesyłania dużych ilości danych podczas przekazywania parametrów (na przykład ciągów dłuższych niż 1 milion znaków), może to niekorzystnie wpłynąć na wydajność serwera.
• Nie można przekazywać parametrów zawierających odwołanie cykliczne, zarówno z serwera do klienta, jak i odwrotnie. Jeśli spróbujesz przekazać taki parametr, aplikacja kliencka ulegnie awarii (nawet jeśli serwer spróbuje wysłać nieprawidłowy parametr).
• Nie zaleca się przekazywania bardzo złożonych zbiorów danych. Jeśli spróbujesz przekazać parametr z bardzo dużym poziomem zagnieżdżenia, serwer ulegnie awarii (! ).

Uwaga! Najbardziej irytującą obecnie funkcją jest prawdopodobnie błąd w przekazywaniu złożonych kolekcji wartości. Na przykład kod: NestingLevel = 1250;
M = Nowa tablica;
PassedParameter = M;
Dla N = 1 przez zagnieżdżanie pętli poziomu
MVInt = Nowa tablica;
M.Add(MVInt);
M = MVin;
koniec cyklu;
ServerFunction(PassedParameter);

Powoduje awarię serwera, rozłączając wszystkich użytkowników, a dzieje się to przed przekazaniem kontroli do kodu 1C.

Korzystanie z niezabezpieczonych funkcji po stronie serwera.

Nie wszystkie cechy języka wbudowanego można wykorzystać w kodzie działającym na serwerze aplikacji, ale nawet wśród dostępnych narzędzi istnieje wiele „problematycznych” konstrukcji, które warunkowo można sklasyfikować następująco:

• zdolne do zapewnienia możliwości wykonania kodu, który nie jest zawarty w konfiguracji (grupa „Wykonanie kodu”)
• w stanie dostarczyć aplikacji klienckiej informacje o pliku i system operacyjny użytkownika lub wykonywania czynności niezwiązanych z pracą z danymi („Naruszenie praw”)
• mogące spowodować awarię serwera lub użycie bardzo dużych zasobów (grupa Awaria serwera)
• mogące spowodować awarię klienta (grupa „Awaria klienta”) – ten typ nie jest brany pod uwagę. Przykład: przekazanie zmiennej wartości do serwera.
• błędy w algorytmach programowania (nieskończone pętle, nieograniczona rekurencja itp.) („Błędy programowania”)

Główne znane mi problematyczne konstrukcje (wraz z przykładami) wymieniono poniżej:

Procedura Wykonaj (<Строка>)

Wykonanie kodu. Umożliwia wykonanie fragmentu kodu, który jest do niego przekazywany jako wartość ciągu. Podczas używania na serwerze należy uważać, aby nie używać danych otrzymanych od klienta jako parametru. Na przykład następujące użycie jest niedozwolone:

#Jeśli serwer to
Procedura OnServer(Param1) Eksport
Wykonaj(Param1);
Procedura końcowa
#KoniecJeśli

Wpisz „COMObject” (konstruktor New COMObject(<Имя>, <Имя сервера>))

Tworzy zewnętrzny obiekt COM aplikacji jako USER1CV8SERVER na serwerze aplikacji (lub innym określonym komputerze). W przypadku używania na serwerze upewnij się, że parametry nie są przekazywane z aplikacji klienckiej. Jednak po stronie serwera efektywne jest wykorzystanie tej funkcji podczas importu/eksportu, przesyłania danych przez Internet, implementacji niestandardowych funkcji itp.

GetCOMObject(<Имя файла>, <Имя класса COM>)

Naruszenie praw i wykonanie kodeksu. Podobnie jak poprzednio, pobieranie tylko obiektu COM odpowiadającego plikowi.

Procedury i funkcjeComputerName(), TempFileDirectory(), ProgramDirectory(), WindowsUsers()

Naruszenie praw. Pozwól, wykonując je na serwerze, poznać szczegóły organizacji podsystemu serwera. W przypadku użycia na serwerze upewnij się, że dane nie są przesyłane do klienta lub nie są dostępne dla operatorów bez odpowiedniej autoryzacji. Zwróć szczególną uwagę na fakt, że dane mogą być przekazywane z powrotem w parametrze przekazywanym przez referencję.

Procedury i funkcje do pracy z plikami (CopyFile, FindFiles, MergeFiles i wiele innych), a także typy „Plik”.

Naruszenie praw. Pozwalają one, wykonując je na serwerze, na uzyskanie współdzielonego dostępu do lokalnych (i znajdujących się w sieci) plików dostępnych na prawach użytkownika USER1CV8SERVER. Świadome zastosowanie pozwala na efektywną realizację takich zadań jak import/eksport danych na serwerze.

Pamiętaj, aby sprawdzić prawa użytkownika 1C przed użyciem tych funkcji. Aby sprawdzić prawa użytkownika, możesz użyć następującej konstrukcji w module serwera:

#Jeśli serwer to
Procedura DoWorkOnFile() Eksport
RoleAdministrator = Metadane.Role.Administrator;
Użytkownik = SessionParameters.CurrentUser;
Jeśli User.Roles.Contains(RoleAdministrator) To
//Tutaj wykonywany jest kod do pracy z plikami
KoniecJeżeli;
#KoniecJeśli

Pamiętaj, aby sprawdzić parametry, jeśli korzystasz z tych procedur i funkcji, w przeciwnym razie istnieje ryzyko przypadkowego lub świadomego spowodowania nieodwracalnego uszkodzenia serwera aplikacji 1C, na przykład podczas wykonywania kodu na serwerze:

Path = "C:\Documents and Settings\All Users\Dane aplikacji\1C\1Cv8\";
MoveFile(Path + "srvrib.lst", Path + "HereWhereFileGone");

Po wykonaniu takiego kodu na serwerze, jeśli użytkownik USER1CV8SERVER ma uprawnienia do jego zmiany, jak opisano powyżej, oraz po ponownym uruchomieniu procesu serwera (domyślnie 3 minuty po wylogowaniu wszystkich użytkowników), pojawi się WIELKIE pytanie o uruchomienie serwer. Ale możliwe jest całkowite usunięcie plików ...

Typy „XBase”, „BinaryData”, „XMLReader”, „XMLWriter”, „XSLTransformer”, „ZipFileWrite”, „ZipFileReader”, „TextReader”, „TextWriter”

Naruszenie praw. Pozwalają, wykonując je na serwerze, na dostęp do lokalnych (i znajdujących się w sieci) plików określonych typów oraz ich odczyt/zapis na prawach użytkownika USER1CV8SERVER. Używane świadomie pozwalają na efektywną realizację takich zadań jak import/eksport danych na serwerze, logowanie działania niektórych funkcji, rozwiązywanie zadań administracyjnych. Generalnie zalecenia są takie same jak w poprzednim akapicie, jednak należy rozważyć możliwość przenoszenia danych tych plików (ale nie obiektów tego typu) pomiędzy częścią kliencką a serwerową.

Wpisz „Informacje o systemie”

Naruszenie praw. Pozwala, w przypadku nieprawidłowego użycia i przesłania danych do klienckiej części aplikacji, uzyskać dane o serwerze aplikacji. Pożądane jest ograniczenie prawa użytkowania podczas używania.

Typy „InternetConnection”, „InternetMail”, „InternetProxy”, „HTTPConnection”, „FTPConnection”

Naruszenie praw. Gdy jest używany na serwerze, łączy się ze zdalnym komputerem z serwera aplikacji na prawach USER1CV8SERVER. Zalecenia:

• Kontrola parametrów podczas wywoływania metod.
• Kontrola praw użytkownika 1C.
• Poważne ograniczenia praw dostępu do sieci użytkownika USER1CV8SERVER.
• Poprawna konfiguracja zapory na serwerze aplikacji 1C.

Przy prawidłowym użyciu wygodnie jest zorganizować na przykład dystrybucję poczty e-mail z serwera aplikacji.

Typy „InfobaseUsersManager”, „InfobaseUser”

Naruszenie praw. W przypadku nieprawidłowego zastosowania (w module uprzywilejowanym) możliwe jest dodawanie użytkowników lub zmiana parametrów uprawnień istniejących użytkowników.

Format funkcji

Awaria serwera. Tak! Ta pozornie nieszkodliwa funkcja, jeśli jej parametry nie są kontrolowane i wykonywane na serwerze, może spowodować awarię aplikacji serwera. Błąd objawia się na przykład podczas formatowania liczb i używania trybu wyjściowego wiodących zer i dużej liczby znaków

Format(1, "HTS=999; FHN=");

Mam nadzieję, że ten błąd zostanie naprawiony w kolejnych wydaniach platformy, ale na razie we wszystkich wywołaniach tej funkcji, które można wykonać na serwerze, należy sprawdzić parametry wywołania.

Procedury i funkcje przechowywania wartości (ValueToStringInt, ValueToFile)

Awaria serwera. Te funkcje nie obsługują odwołań cyklicznych w kolekcjach i bardzo głębokiego zagnieżdżania, więc mogą ulec awarii w niektórych bardzo szczególnych przypadkach.

Błędy w wartościach parametrów granicznych i specjalnych w funkcjach. Kontrola wykonania.

Jednym z problemów, jaki można napotkać podczas korzystania z serwera, jest duża „odpowiedzialność” funkcji serwera (możliwość zawieszenia całej aplikacji serwera z powodu błędu w jednym połączeniu i wykorzystania jednej „przestrzeni zasobów” dla wszystkich połączeń) . Stąd konieczność kontroli głównych parametrów runtime:

• W przypadku wbudowanych funkcji językowych sprawdź ich parametry uruchamiania (doskonałym przykładem jest funkcja „Format”)
• Podczas korzystania z pętli upewnij się, że spełniony jest warunek wyjścia z pętli. Jeśli pętla jest potencjalnie nieskończona, sztucznie ogranicz liczbę iteracji: IterationCountMaxValue = 1000000;
  Liczba iteracji = 1;
  Do widzenia
  Funkcja, która może nie zwrócić False()
  ORAZ (liczniki iteracji<МаксимальноеЗначениеСчетчикаИтераций) Цикл

  //.... Treść pętli
  Liczba iteracji = Liczba iteracji + 1;
  koniec cyklu;
  Jeśli IterationCount>IterationCountMaxValue To
  //...obsługa zdarzenia wykonania zbyt długiej pętli
  KoniecJeżeli;

• Ogranicz maksymalny poziom zagnieżdżenia podczas korzystania z rekurencji.
• Podczas tworzenia i wykonywania zapytań staraj się unikać bardzo długich pobrań i pobrań dużej ilości informacji (na przykład, używając warunku „IN HIERARCHY”, nie używaj pustej wartości)
• Projektując bazę danych, zapewnij odpowiednio duży margines na liczby (w przeciwnym razie dodawanie i mnożenie stanie się nieprzemienne i nieasocjacyjne, co utrudnia debugowanie)
• W wykonywalnych zapytaniach sprawdź logikę działania pod kątem obecności wartości NULL oraz poprawności działania warunków zapytania i wyrażeń z wykorzystaniem NULL.
• W przypadku korzystania z kolekcji należy kontrolować, czy można je przekazywać między serwerem aplikacji a stroną klienta.

Korzystanie z dostępu do terminala po stronie klienta w celu ograniczenia dostępu

Nierzadko pojawiają się zalecenia dotyczące korzystania z dostępu do terminala w celu ograniczenia dostępu do danych i poprawy wydajności poprzez wykonywanie kodu po stronie klienta na serwerze terminali. Owszem, przy odpowiedniej konfiguracji korzystanie z dostępu terminalowego może realnie podnieść ogólny poziom bezpieczeństwa systemu, ale niestety często można spotkać się z tym, że w praktyce bezpieczeństwo systemu tylko spada. Spróbujmy dowiedzieć się, z czym jest to związane. Obecnie istnieją dwa popularne sposoby organizacji dostępu do terminali, są to Microsoft Terminal Services (protokół RDP) i Citrix Metaframe Server (protokół ICA). Ogólnie rzecz biorąc, narzędzia Citrix zapewniają znacznie bardziej elastyczne opcje administrowania dostępem, ale koszt tych rozwiązań jest znacznie wyższy. Rozważymy tylko główne cechy wspólne dla obu protokołów, które mogą obniżyć ogólny poziom bezpieczeństwa. Korzystanie z dostępu do terminala wiąże się tylko z trzema głównymi zagrożeniami:

• Możliwość blokowania pracy innych użytkowników poprzez przechwytywanie nadmiernej ilości zasobów
• Dostęp do danych innych użytkowników.
• Nieautoryzowane kopiowanie danych z serwera terminali na komputer użytkownika

W każdym przypadku Usługi terminalowe umożliwiają:

• Zwiększ niezawodność pracy (w przypadku awarii komputera końcowego użytkownik może później kontynuować pracę z tego samego miejsca)
• Ogranicz dostęp do aplikacji klienckiej i zapisywanych przez nią plików.
• Przenieś obciążenie obliczeniowe z miejsca pracy użytkownika na serwer dostępu do terminala
• Zarządzaj ustawieniami systemowymi bardziej centralnie. Dla użytkowników zapisane ustawienia będą obowiązywać niezależnie od komputera, z którego logowali się do systemu.
• W niektórych przypadkach można użyć rozwiązania terminalowego do zdalnego dostępu do systemu.

Konieczne jest ograniczenie liczby możliwych połączeń z serwerem terminali jednego użytkownika

Ze względu na „obżarstwo” aplikacji klienckiej 1C w zakresie zasobów konieczne jest ograniczenie maksymalnej liczby jednoczesnych połączeń jednego użytkownika (operatora) z serwerem terminali. Aktywne połączenie może wykorzystywać do 300 MB pamięci z tylko jedną instancją aplikacji. Oprócz pamięci aktywnie wykorzystywany jest czas procesora, co również nie wpływa na stabilność pracy użytkowników tego serwera. Równocześnie z zapobieganiem nadmiernemu wykorzystaniu zasobów serwera, takie ograniczenie może uniemożliwić korzystanie z cudzych konto. Wdrożone przez standardowe ustawienia serwera terminali.

Nie wolno zezwalać na jednoczesne działanie więcej niż jednej lub dwóch aplikacji klienckich 1C w jednym połączeniu

Jest to podyktowane tymi samymi powodami, co w poprzednim akapicie, ale jest technicznie trudniejsze do wykonania. Problem polega na tym, że prawie niemożliwe jest uniemożliwienie ponownego uruchomienia 1C za pomocą serwera terminali (zostanie to wyjaśnione poniżej dlaczego), więc musisz zaimplementować tę funkcję na poziomie rozwiązania aplikacji (co również nie jest dobrym rozwiązaniem, ponieważ może być „zawieszonymi” sesjami przez jakiś czas, gdy aplikacja kończy się niepoprawnie, konieczne staje się dopracowanie rozwiązania aplikacji w module aplikacji i niektórych katalogach, co skomplikuje korzystanie z aktualizacji z 1C). Bardzo pożądane jest pozostawienie użytkownikowi możliwości uruchamiania 2 aplikacji, aby móc wykonywać niektóre czynności (np. generowanie raportów) w tle - aplikacja kliencka jest niestety tak naprawdę jednowątkowa.

Nie zaleca się nadawania praw dostępu do serwera terminali użytkownikom, którzy mają prawo do wykonywania zadań obliczeniowych wymagających dużej ilości zasobów w 1C lub zapobiegania takiemu uruchomieniu podczas aktywnej pracy innych użytkowników.

Oczywiście lepiej pozostawić dostęp do serwera terminali tylko użytkownikom, którzy nie korzystają z takich zadań jak analiza danych (data mining), schematy geograficzne, import/eksport i inne zadania poważnie obciążające kliencką stronę aplikacji. Jeżeli mimo wszystko zaistnieje potrzeba rozwiązania takich zadań, wówczas konieczne jest: powiadomienie użytkownika, że ​​zadania te mogą mieć wpływ na działanie innych użytkowników, odnotowanie w dzienniku zdarzenia rozpoczęcia i zakończenia takiego zadania proces, aby umożliwić wykonanie tylko w zaplanowanych godzinach itp.

Należy upewnić się, że każdy użytkownik ma prawo zapisu tylko do ściśle określonych katalogów serwera terminali i że inni użytkownicy nie mają do nich dostępu.

Po pierwsze, jeśli nie ograniczysz możliwości zapisu do współdzielonych katalogów (takich jak katalog, w którym jest zainstalowany 1C), atakujący nadal ma możliwość zmiany zachowania programu dla wszystkich użytkowników. Po drugie, dane jednego użytkownika (pliki tymczasowe, pliki zapisywania ustawień raportów itp.) w żadnym wypadku nie powinny być dostępne dla innego użytkownika serwera terminali – generalnie podczas normalnej konfiguracji przestrzegana jest ta zasada. Po trzecie, atakujący nadal ma możliwość „zaśmiecenia” partycji, tak aby na dysku twardym nie było już miejsca. Wiem, że ktoś zarzuci, że od Windows 2000 Windows ma mechanizm kwotowania, ale jest to dość kosztowny mechanizm i praktycznie nigdy nie widziałem jego rzeczywistego zastosowania.

O ile poprzednie zagadnienia ustawiania dostępu były generalnie dość łatwe do zrealizowania, to tak (z pozoru) proste zadanie, jak regulowanie dostępu użytkowników do plików, nie jest trywialne. Po pierwsze, jeśli mechanizm kwotowania nie jest używany, można zapisywać duże pliki. Po drugie, system jest zbudowany w taki sposób, że prawie zawsze będzie można zapisać plik, aby był dostępny dla innego użytkownika.

Biorąc pod uwagę, że zadanie jest trudne do całkowitego rozwiązania, zaleca się audyt większości zdarzeń w plikach

Należy zakazać podłączania (mapowania) urządzeń dyskowych, drukarek oraz schowka stacji klienckiej.

W RDP i ICA istnieje możliwość zorganizowania automatycznego podłączenia dysków, drukarek, portów schowka komputera terminala do serwera. Jeśli taka możliwość istnieje, praktycznie niemożliwe jest zakazanie uruchamiania obcego kodu na serwerze terminali i zapisywania danych z 1C na kliencie dostępu do terminala. Zezwól na te funkcje tylko osobom z uprawnieniami administracyjnymi.

Dostęp do plików sieciowych z serwera terminali musi być ograniczony.

Jeśli nie zostanie to zrobione, użytkownik ponownie będzie mógł uruchomić niechciany kod lub zapisać dane. Ponieważ zwykły dziennik nie śledzi zdarzeń związanych z plikami (nawiasem mówiąc, dobry pomysł do wdrożenia dla twórców platform), a skonfigurowanie audytu systemu w całej sieci jest prawie niemożliwe (nie ma wystarczających zasobów, aby go utrzymać), lepiej, aby użytkownik mógł przesłać dane lub wydrukować je lub wysłać e-mailem. Zwróć szczególną uwagę na fakt, że serwer terminali nie współpracuje bezpośrednio z nośnikami wymiennymi użytkownika.

W żadnym wypadku podczas tworzenia bezpiecznego systemu nie należy pozostawiać serwera aplikacji na serwerze terminali.

Jeśli serwer aplikacji działa na tym samym komputerze co aplikacje klienckie, istnieje sporo możliwości zakłócenia jego normalnego działania. Jeśli z jakiegoś powodu nie da się rozdzielić funkcji serwera terminali i serwera aplikacji, należy zwrócić szczególną uwagę na dostęp użytkowników do plików wykorzystywanych przez serwer aplikacji.

Konieczne jest wykluczenie możliwości uruchamiania wszystkich aplikacji oprócz 1C:Enterprise na serwerze terminali.

To jedno z najtrudniejszych do spełnienia życzeń. Zacznijmy od tego, że konieczne jest poprawne skonfigurowanie polityki bezpieczeństwa grupy w domenie. Wszystkie „Szablony administracyjne” i „Zasady ograniczeń oprogramowania” muszą być poprawnie skonfigurowane. Aby się sprawdzić, upewnij się, że co najmniej następujące opcje są wyłączone:

Złożoność wdrożenia tego wymogu często prowadzi do możliwości uruchomienia „dodatkowej” sesji 1C na serwerze terminali (nawet jeśli inne aplikacje są ograniczone, nie można w zasadzie zabronić uruchamiania 1C przy użyciu systemu Windows).

Weź pod uwagę ograniczenia zwykłego dziennika rejestracji (wszyscy użytkownicy korzystają z programu z jednego komputera)

Oczywiście, ponieważ użytkownicy otwierają 1C w trybie terminalowym, to serwer terminali zostanie zarejestrowany w dzienniku rejestracji. Dziennik rejestracji nie informuje, z jakiego komputera użytkownik się łączył.

Serwer terminali — ochrona czy luka w zabezpieczeniach?

Tak więc, po rozważeniu głównych cech północnej części terminali, możemy powiedzieć, że potencjalnie północna część terminali może pomóc w automatyzacji dystrybucji obciążenia obliczeniowego, ale zbudowanie bezpiecznego systemu jest dość trudne. Jednym z przypadków, w których korzystanie z serwera terminali jest najbardziej efektywne, jest uruchamianie 1C bez Eksploratora Windows w trybie pełnoekranowym dla użytkowników o ograniczonej funkcjonalności i specjalistycznym interfejsie.

Praca po stronie klienta

Korzystanie z Internet Explorera (IE)

Jednym z warunków normalnego działania części klienckiej 1C jest użycie komponentów Internet Explorera. Z tymi składnikami trzeba być bardzo ostrożnym.

Uwaga! Po pierwsze, jeśli moduł spyware lub adware jest „dołączony” do IE, zostanie załadowany, nawet jeśli jakiekolwiek pliki HTML będą przeglądane w 1C. Do tej pory nie widziałem świadomego użycia tej funkcji, ale widziałem w jednej z organizacji załadowany moduł „szpiegowski” jednej z sieci pornograficznych, gdy działa 1C (program antywirusowy nie był aktualizowany, których objawy zostały znalezione: podczas konfigurowania zapory było jasne, że 1C próbuje na porcie 80 połączyć się ze stroną pornograficzną). Właściwie jest to kolejny argument przemawiający za tym, aby ochrona była kompleksowa.

Uwaga! Po drugie, system 1C umożliwia korzystanie z filmów flash, obiektów ActiveX, VBScript w wyświetlanych dokumentach HTML, wysyłanie danych do Internetu, a nawet otwieranie plików PDF (!), To prawda, w tym drugim przypadku pyta „otwórz lub zapisz” .. Ogólnie rzecz biorąc, czego dusza zapragnie. Przykład nie do końca rozsądnego wykorzystania wbudowanej możliwości przeglądania i edycji HTML:

• Utwórz nowy dokument HTML (Plik -> Nowy -> Dokument HTML).
• Przejdź do zakładki „Tekst” pustego dokumentu.
• Usuń tekst (całkowicie).
• Przejdź do zakładki „Widok” tego dokumentu
• Za pomocą funkcji „przeciągnij i upuść” przenieś plik z rozszerzeniem SWF (są to pliki filmów flash) z otwartego eksploratora do okna dokumentu, na przykład z pamięci podręcznej przeglądarki, chociaż jest to możliwe z zabawką FLASH dla zabawy.
• Jak słodko! Na 1C możesz uruchomić zabawkę!

Z punktu widzenia bezpieczeństwa systemu jest to całkowicie błędne. Jak dotąd nie widziałem specjalnych ataków na 1C przez tę lukę, ale najprawdopodobniej okaże się to kwestią czasu i wartości twoich informacji.

Podczas pracy z polem w dokumencie HTML pojawia się kilka innych pomniejszych punktów, ale te dwa wymienione są najważniejsze. Chociaż, jeśli twórczo podejdziesz do tych funkcji, możesz zorganizować naprawdę niesamowite możliwości interfejsu do pracy z 1C.

Korzystanie z zewnętrznych raportów i przetwarzania.

Uwaga! Zewnętrzne raporty i przetwarzanie - z jednej strony - wygodnym sposobem wdrożenie dodatkowych formularzy drukowanych, raportów regulacyjnych, raportów specjalistycznych, z drugiej strony potencjalny sposób na ominięcie wielu ograniczeń bezpieczeństwa systemu i zakłócenie działania serwera aplikacji (przykład patrz wyżej w „Przekazywanie parametrów”). System 1C ma specjalny parametr w zestawie uprawnień roli „Interaktywne otwieranie przetwarzania zewnętrznego”, ale to nie eliminuje całkowicie problemu - dla pełnego rozwiązania konieczne jest zawężenie kręgu użytkowników, którzy mogą zarządzać zewnętrzne formularze drukarskie, rutynowe raporty i inne stałe cechy standardowych rozwiązań realizowanych z wykorzystaniem przetwarzania zewnętrznego. Na przykład domyślnie w SCP wszystkie główne role użytkowników mają możliwość pracy z katalogiem dodatkowych formularzy drukowania, a to w rzeczywistości jest możliwość korzystania z dowolnego przetwarzania zewnętrznego.

Wykorzystanie standardowych mechanizmów standardowych rozwiązań i platformy (wymiana danych)

Niektóre standardowe mechanizmy są potencjalnie niebezpieczne i to w dość nieoczekiwany sposób.

Drukowanie list

Dowolną listę (na przykład katalog lub rejestr informacji) w systemie można wydrukować lub zapisać do pliku. W tym celu wystarczy skorzystać ze standardowej funkcji dostępnej z menu kontekstowego oraz menu „Akcje”:

Należy pamiętać, że praktycznie wszystko, co użytkownik widzi na listach, można zapisać w zewnętrznych plikach. Jedyne, co można doradzić, to zachowanie protokołu drukowania dokumentów na serwerach wydruku. Dla szczególnie krytycznych formularzy konieczne jest takie skonfigurowanie panelu akcji powiązanego z chronionym polem tabeli, aby nie była dostępna możliwość wyświetlenia listy z tego panelu oraz wyłączenie menu kontekstowego (patrz rysunek 6).

Wymiana danych w rozproszonej bazie danych

Format wymiany danych jest dość prosty i opisany w dokumentacji. Jeśli użytkownik ma możliwość podmiany kilku plików, może dokonać nieautoryzowanych zmian w systemie (choć jest to zadanie dość pracochłonne). Możliwość tworzenia brzegowej bazy danych podczas korzystania z planów wymiany rozproszonych baz danych nie powinna być dostępna dla zwykłych operatorów.

Standardowa wymiana danych XML

W standardowej wymianie danych, która jest wykorzystywana do wymiany pomiędzy typowymi konfiguracjami (np. „Zarządzanie handlem” i „Księgowość przedsiębiorstwa”), w regułach wymiany można określić procedury obsługi zdarzeń załadunku i rozładunku obiektu. Jest to realizowane poprzez pobranie handlera z pliku oraz procedurę „Execute()” standardowego przetwarzania ładowania i wyładowywania pliku (po stronie klienta uruchamiana jest procedura „Execute()”). Oczywiście nie jest trudno stworzyć taki fałszywy plik wymiany, który będzie wykonywał złośliwe działania. W przypadku większości ogólnych ról użytkowników rozwiązania udostępnianie jest domyślnie włączone.

Rekomendacje: ograniczyć dostęp do wymiany XML dla większości użytkowników (pozostawić tylko administratorom bezpieczeństwa informacji). Prowadź dzienniki uruchomień tego przetwarzania, zapisując plik wymiany, na przykład wysyłając go e-mail administratora IS przed pobraniem.

Używanie ogólnych raportów, zwłaszcza konsoli raportowania

Inną kwestią jest domyślny dostęp użytkownika do raportów ogólnych, zwłaszcza raportu Konsoli raportów. Ten raport charakteryzuje się tym, że pozwala wykonać prawie wszystkie żądania bezpieczeństwa informacji, a nawet jeśli system praw 1C (w tym RLS) jest skonfigurowany dość sztywno, pozwala użytkownikowi uzyskać wiele „niepotrzebnych” informacji i zmusić serwer do wykonania takiego żądania, które zabierze wszystkie zasoby systemowe.

Korzystanie z trybu pełnoekranowego (tryb pulpitu)

Jednym ze skutecznych sposobów organizacji wyspecjalizowanych interfejsów z ograniczonym dostępem do funkcjonalności programu jest tryb pełnoekranowy głównej (i być może jedynej) formy wykorzystywanego interfejsu. Jednocześnie nie ma problemów z dostępnością np. menu „Plik”, a wszelkie działania użytkownika są ograniczone możliwościami zastosowanego formularza. Szczegółowe informacje znajdują się w części „Funkcje implementacji trybu pulpitu” na dysku ITS.

Kopia zapasowa

Kopię zapasową dla wersji klient-serwer 1C można wykonać na dwa sposoby: przesyłanie danych do pliku z rozszerzeniem dt i tworzenie kopii zapasowych za pomocą SQL. Pierwsza metoda ma wiele wad: wymagany jest wyłączny dostęp, samo tworzenie kopii trwa znacznie dłużej, w niektórych przypadkach (w przypadku naruszenia struktury SI) utworzenie archiwum jest niemożliwe, ale jest jedna zaleta - minimalny rozmiar archiwum. W przypadku kopii zapasowej SQL jest odwrotnie: kopia tworzona jest w tle przy użyciu serwera SQL, ze względu na prostą strukturę i brak kompresji jest to proces bardzo szybki i o ile fizyczna integralność bazy danych SQL jest nie zostanie naruszony, wykonywana jest kopia zapasowa, ale rozmiar kopii jest taki sam, jak prawdziwy rozmiar IB w stanie rozwiniętym (kompresja nie jest wykonywana). Ze względu na dodatkowe zalety systemu backupu MS SQL bardziej celowe jest jego stosowanie (dopuszczalne są 3 rodzaje backupów: pełny, różnicowy, kopia dziennika transakcji; możliwe jest tworzenie regularnie wykonywanych zadań; kopia zapasowa i szybkie wdrożenie systemu backupu, możliwość przewidywania wielkości wymaganej przestrzeni dyskowej itp.). Główne punkty organizacji backupu pod kątem bezpieczeństwa systemu to:

• Konieczność wyboru miejsca przechowywania kopii zapasowych w taki sposób, aby nie były one dostępne dla użytkowników.
• Konieczność przechowywania kopii zapasowych w fizycznej odległości od serwera MS SQL (na wypadek klęsk żywiołowych, pożarów, ataków itp.)
• Możliwość nadania uprawnień do rozpoczęcia tworzenia kopii zapasowych użytkownikowi, który nie ma dostępu do kopii zapasowych.

Aby uzyskać więcej informacji, zapoznaj się z dokumentacją MS SQL.

Szyfrowanie danych

Do ochrony danych przed nieautoryzowanym dostępem często stosuje się różne narzędzia kryptograficzne (zarówno programowe, jak i sprzętowe), jednak ich celowość w dużej mierze zależy od prawidłowej aplikacji i ogólnego bezpieczeństwa systemu. Rozważymy szyfrowanie danych na różnych etapach transmisji i przechowywania danych przy użyciu najpowszechniejszych środków oraz główne błędy projektowe systemów z wykorzystaniem narzędzi kryptograficznych.

Istnieje kilka głównych etapów przetwarzania informacji, które można chronić:

• Transfer danych pomiędzy kliencką częścią systemu a serwerem aplikacji
• Transfer danych pomiędzy serwerem aplikacji a MS SQL Server
• Dane przechowywane na MS SQL Server (pliki danych na dysku fizycznym)
• Szyfrowanie danych przechowywanych w IB
• Dane zewnętrzne (w związku z bezpieczeństwem informacji)

W przypadku danych przechowywanych po stronie klienta i na serwerze aplikacji (zapisane ustawienia użytkownika, lista IB itp.) szyfrowanie jest uzasadnione tylko w bardzo rzadkich przypadkach i dlatego nie jest tutaj rozpatrywane. Podczas korzystania z narzędzi kryptograficznych nie należy zapominać, że ich użycie może znacznie obniżyć wydajność systemu jako całości.

Ogólne informacje na temat ochrony kryptograficznej połączeń sieciowych przy wykorzystaniu protokołu TCP/IP.

Bez ochrony wszystkie połączenia sieciowe są narażone na nieautoryzowany nadzór i dostęp. Aby je chronić, można zastosować szyfrowanie danych na poziomie protokołu sieciowego. Do szyfrowania danych przesyłanych w sieci lokalnej najczęściej wykorzystywane są narzędzia IPSec dostarczane przez system operacyjny.

Narzędzia IPSec zapewniają szyfrowanie przesyłanych danych za pomocą algorytmów DES i 3DES oraz kontrolę integralności za pomocą funkcji skrótu MD5 lub SHA1. IPSec może działać w dwóch trybach: trybie transportowym i trybie tunelowym. Tryb transportu jest lepszy do zabezpieczania połączeń w sieci lokalnej. Tryb tunelowy może służyć do organizowania połączeń VPN między oddzielnymi segmentami sieci lub do ochrony zdalnego połączenia z siecią lokalną za pośrednictwem otwartych kanałów danych.

Główne zalety tego podejścia to:

• Możliwość centralnego zarządzania bezpieczeństwem za pomocą narzędzi Active Directory.
• Możliwość wykluczenia nieautoryzowanych połączeń z serwerem aplikacji i serwerem MS SQL (np. możliwe jest zabezpieczenie przed nieautoryzowanym dodaniem zabezpieczeń informacji na serwerze aplikacji).
• Wyjątek „nasłuchuje” ruchu sieciowego.
• Nie ma potrzeby zmiany zachowania programów aplikacyjnych (w tym przypadku 1C).
• Standard takiego rozwiązania.

Jednak to podejście ma ograniczenia i wady:

• IPSec nie chroni danych przed manipulacją i podsłuchiwaniem bezpośrednio na komputerach źródłowych i docelowych.
• Ilość danych przesyłanych przez sieć jest nieco większa niż bez użycia IPSec.
• Podczas korzystania z IPSec obciążenie centralnego procesora jest nieco większe.

Szczegółowy opis implementacji IPSec wykracza poza zakres tego artykułu i wymaga zrozumienia podstawowych zasad protokołu IP. Aby poprawnie skonfigurować zabezpieczenia połączenia, zapoznaj się z odpowiednią dokumentacją.

Osobno należy wspomnieć o kilku aspektach umowy licencyjnej z 1C podczas organizowania połączeń VPN. Faktem jest, że pomimo braku ograniczeń technicznych, przy łączeniu kilku segmentów sieci lokalnej lub zdalnym dostępie pojedynczego komputera do sieci lokalnej zwykle wymaganych jest kilka podstawowych materiałów eksploatacyjnych.

Szyfrowanie danych podczas transmisji pomiędzy kliencką częścią systemu a serwerem aplikacji.

Oprócz szyfrowania na poziomie protokołu sieciowego istnieje możliwość szyfrowania danych na poziomie protokołu COM+, o czym mowa w artykule „Regulacja dostępu użytkowników do bazy danych w wersji klient-serwer” ITS. Aby to zaimplementować, musisz ustawić „Usługi składowe” dla aplikacji 1CV8, aby ustawić poziom uwierzytelniania dla połączeń na „Prywatność pakietów”. Po ustawieniu tego trybu pakiet jest uwierzytelniany i szyfrowany, w tym dane oraz tożsamość i podpis nadawcy.

Szyfrowanie danych podczas transmisji pomiędzy serwerem aplikacji a MS SQL Server

MS SQL Server udostępnia następujące narzędzia do szyfrowania danych:

• Istnieje możliwość wykorzystania protokołu Secure Sockets Layer (SSL) podczas przesyłania danych pomiędzy serwerem aplikacji a MS SQL Server.
• W przypadku korzystania z biblioteki sieciowej Multiprotocol szyfrowanie danych jest stosowane na poziomie RPC. Jest to potencjalnie słabsze szyfrowanie niż w przypadku SSL.
• Jeśli używany jest protokół wymiany Shared Memory (dzieje się tak, gdy serwer aplikacji i MS SQL Server znajdują się na tym samym komputerze), to w żadnym wypadku nie jest stosowane szyfrowanie.

Aby ustawić potrzebę szyfrowania wszystkich przesyłanych danych dla określonego serwera MS SQL, użyj narzędzia „Server Network Utility”. Uruchom go i na karcie „Ogólne” zaznacz pole „Wymuś szyfrowanie protokołu”. Metoda szyfrowania jest wybierana w zależności od metody używanej przez aplikację kliencką (tj. Serwer aplikacji 1C). Aby korzystać z SSL, musisz odpowiednio skonfigurować usługę wystawiania certyfikatów w swojej sieci.

Aby ustawić potrzebę szyfrowania wszystkich przesyłanych danych dla określonego serwera aplikacji, musisz użyć narzędzia „Client Network Utility” (zwykle znajduje się w „C:\WINNT\system32\cliconfg.exe”). Podobnie jak w poprzednim przypadku, na zakładce „Ogólne” zaznacz pole „Wymuś szyfrowanie protokołu”.

Należy mieć na uwadze, że zastosowanie szyfrowania w tym przypadku może mieć znaczący wpływ na wydajność systemu, szczególnie w przypadku korzystania z zapytań zwracających duże ilości informacji.

W celu pełniejszego zabezpieczenia połączenia pomiędzy serwerem aplikacji a MS SQL Server przy wykorzystaniu protokołu TCP/IP możemy zalecić kilka zmian w ustawieniach domyślnych.

Po pierwsze, możesz ustawić port inny niż standardowy (domyślnie używany jest port 1433). Jeśli zdecydujesz się na użycie niestandardowego portu TCP do wymiany danych, pamiętaj, że:

• MS SQL Server i Application Server muszą używać tego samego portu.
• W przypadku korzystania z zapór sieciowych ten port musi być dozwolony.
• Nie można ustawić portu, który może być używany przez inne aplikacje na serwerze MS SQL. Aby uzyskać informacje, zobacz http://www.ise.edu/in-notes/iana/assignments/port-numbers (adres zaczerpnięty z SQL Server Books Online).
• W przypadku korzystania z wielu instancji usługi MS SQL Server należy zapoznać się z dokumentacją MS SQL (sekcja „Konfigurowanie połączeń sieciowych”) w celu konfiguracji.

Po drugie, w ustawieniach protokołu TCP/IP na serwerze MS SQL można ustawić opcję „Ukryj serwer”, która zabrania odpowiadania na żądania rozgłaszania do tej instancji usługi MS SQL Server.

Szyfrowanie danych MS SQL przechowywanych na dysku

Istnieje dość duży wybór oprogramowania i sprzętu do szyfrowania danych znajdujących się na dysku lokalnym (jest to zwykła zdolność systemu Windows do korzystania z EFS i korzystania z kluczy eToken oraz programów innych firm, takich jak Jetico Bestcrypt lub PGPDisk). Jednym z głównych zadań realizowanych przez te narzędzia jest ochrona danych w przypadku utraty nośnika (np. w przypadku kradzieży serwera). Należy szczególnie zauważyć, że Microsoft nie zaleca przechowywania baz danych MS SQL na zaszyfrowanych nośnikach i jest to całkiem uzasadnione. Głównym problemem w tym przypadku jest znaczny spadek wydajności i możliwe problemy niezawodność awarii. Drugim czynnikiem komplikującym życie administratora systemu jest konieczność zapewnienia dostępności wszystkich plików bazy danych w momencie pierwszego dostępu do nich przez usługę MS SQL (tzn. jest połączone).

Aby uniknąć zauważalnego spadku wydajności systemu, można wykorzystać możliwości MS SQL do tworzenia baz danych w kilku plikach. Oczywiście w tym przypadku baza danych MS SQL nie powinna być tworzona przez serwer 1C podczas tworzenia bazy danych, ale powinna być tworzona osobno. Przykładowy skrypt w TSQL z komentarzami podano poniżej:

USEmaster
IŚĆ
-- Utwórz bazę danych SomeData,
UTWÓRZ BAZY DANYCH SomeData
-- którego wszystkie dane znajdują się w grupie plików PRIMARY.
NA PODSTAWOWYM
-- Główny plik danych znajduje się na zaszyfrowanym nośniku (dysk logiczny E:)
-- i ma początkowy rozmiar 100 MB, może zostać automatycznie zwiększony do 200 MB za pomocą
-- krok 20 MB
(NAZWA = NiektóreDane1,
NAZWA PLIKU = "E:\SomeData1.mdf",
ROZMIAR = 100 MB,
MAKSYMALNY ROZMIAR=200
WZROST PLIKÓW=2),
-- Drugi plik danych znajduje się na niezaszyfrowanym nośniku (dysk logiczny C:)
-- i ma początkowy rozmiar 100 MB, może zostać automatycznie zwiększony do limitu
-- miejsce na dysku w krokach co 5% bieżącego rozmiaru pliku (w zaokrągleniu do 64 KB)
(NAZWA = NiektóreDane2,
NAZWA PLIKU = "c:\program files\microsoft sql server\mssql\data\SomeData2.ndf",
ROZMIAR = 100 MB,
MAKSYMALNY ROZMIAR=NIEOGRANICZONY,
WZROST PLIKÓW = 5%)
ZALOGOWAĆ SIĘ
-- Chociaż dziennik transakcji można również podzielić na części, nie należy tego robić,
-- ponieważ ten plik zmienia się znacznie częściej i jest regularnie czyszczony (na przykład kiedy
-- tworzenie kopii zapasowej bazy danych).
(NAZWA = jakiś dziennik danych,
NAZWA PLIKU = "c:\program files\microsoft sql server\mssql\data\SomeData.ldf",
ROZMIAR = 10 MB,
MAKSYMALNY ROZMIAR=NIEOGRANICZONY,
WZROST PLIKÓW=10)
IŚĆ
-- Lepiej od razu przekazać własność bazy danych użytkownikowi, w czyim imieniu
-- 1C zostanie podłączony. W tym celu musimy zadeklarować aktualną bazę
- właśnie utworzone
WYKORZYSTAJ Niektóre dane
IŚĆ
-- i uruchom sp_changedbowner
EXEC sp_changedbowner @logname = "SomeData_dbowner"

Mała dygresja na temat automatycznego zwiększania rozmiaru pliku danych. Domyślnie w przypadku tworzonych baz danych rozmiary plików zwiększają się o 10% bieżącego rozmiaru pliku. Jest to całkowicie akceptowalne rozwiązanie dla małych baz danych, ale niezbyt dobre dla dużych: przy rozmiarze bazy danych, na przykład 20 GB, plik powinien powiększyć się o 2 GB naraz. Choć zdarzenie to będzie występowało sporadycznie, może trwać kilkadziesiąt sekund (wszystkie inne transakcje są w tym czasie faktycznie bezczynne), co jeśli wystąpi podczas aktywnej pracy z bazą danych, może spowodować pewne awarie. Drugim negatywnym skutkiem proporcjonalnego przyrostu, który pojawia się, gdy miejsce na dysku jest prawie całkowicie zapełnione, jest możliwość przedwczesnej awarii z powodu braku wolnego miejsca. Na przykład, jeśli partycja dysku o pojemności 40 GB jest całkowicie przydzielona dla jednej bazy danych (a dokładniej dla jednego pliku tej bazy danych), to krytyczny rozmiar pliku bazy danych, przy którym należy pilnie (bardzo pilnie, do przerwy w normalnej pracy użytkownika) reorganizacji przechowywania informacji to plik danych o wielkości 35 GB. Przy rozmiarze przyrostu ustawionym na 10-20 MB możesz kontynuować pracę, aż osiągniesz 39 GB.

Dlatego chociaż powyższy listing określa zwiększanie rozmiaru jednego z plików bazy danych w krokach co 5%, to dla dużych rozmiarów baz danych lepiej jest ustawić stały przyrost 10-20 MB. Podczas ustawiania wartości kroku wzrostu dla rozmiaru plików bazy danych należy wziąć pod uwagę, że dopóki jeden z plików w grupie plików nie osiągnie maksymalnego rozmiaru, obowiązuje zasada: pliki z jednej grupy plików rosną wszystkie w tym samym czasie, gdy wszystkie są całkowicie wypełnione. Tak więc w powyższym przykładzie, gdy plik SomeData1.mdf osiągnie maksymalny rozmiar 200 MB, plik SomeData2.ndf będzie miał rozmiar około 1,1 GB.

Po utworzeniu takiej bazy danych, nawet jeśli jej niezabezpieczone pliki SomeData2.ndf i SomeData.ldf staną się dostępne dla atakującego, niezwykle trudno będzie przywrócić prawdziwy stan bazy danych – dane (w tym informacje o logicznej strukturze bazy danych ) będą rozproszone po kilku plikach, ponadto kluczowe informacje (na przykład o tym, które pliki tworzą tę bazę danych) będą znajdować się w zaszyfrowanym pliku.

Oczywiście, jeśli pliki bazy danych są przechowywane przy użyciu środków kryptograficznych, to nie należy wykonywać kopii zapasowych (przynajmniej tych plików) na niezaszyfrowanych nośnikach. Aby zapewnić utworzenie kopii zapasowej poszczególnych plików bazy danych, użyj odpowiedniej składni polecenia „BACKUP DATABASE”. Należy pamiętać, że pomimo możliwości zabezpieczenia hasłem kopii zapasowej bazy danych (opcje „HASŁO=” i „MEDIAPASSWORD=” polecenia „BACKUP DATABASE”) taka kopia zapasowa nie jest szyfrowana!

Szyfrowanie danych serwera aplikacji i klienta przechowywanych na dyskach

W większości przypadków przechowywanie plików używanych przez 1C:Enterprise (część klienta i serwer aplikacji) na zaszyfrowanych nośnikach nie może być uznane za uzasadnione ze względu na nieuzasadnione wysokie koszty, jednak jeśli taka potrzeba istnieje, należy pamiętać, że serwer aplikacji i część klienta aplikacji bardzo często tworzą pliki tymczasowe. Często pliki te mogą pozostać po zakończeniu działania aplikacji i prawie niemożliwe jest zagwarantowanie ich usunięcia za pomocą narzędzi 1C. W związku z tym powstaje szyfrowanie katalogu używanego do plików tymczasowych w 1C lub nie przechowywanie go na dysku za pomocą napędu RAM (ta ostatnia opcja nie zawsze jest możliwa ze względu na rozmiar generowanych plików i wymagania dotyczące ilości pamięci RAM samej aplikacji 1C:Enterprise).

Szyfrowanie danych za pomocą wbudowanych narzędzi 1C.

Regularne możliwości korzystania z szyfrowania w 1C sprowadzają się do używania obiektów do pracy z plikami Zip z parametrami szyfrowania. Dostępne są następujące tryby szyfrowania: algorytm AES z kluczem o długości 128, 192 lub 256 bitów oraz przestarzały algorytm pierwotnie używany w archiwizatorze Zip. Pliki ZIP zaszyfrowane za pomocą AES nie są odczytywane przez wiele archiwizatorów (WinRAR, 7zip). Aby wygenerować plik zawierający zaszyfrowane dane, należy podać hasło i algorytm szyfrowania. Najprostszy przykład funkcji szyfrowania-deszyfrowania opartych na tej funkcji podano poniżej:

Funkcja EncryptData(dane, hasło, metoda szyfrowania = niezdefiniowana) Eksportuj

// Zapisz dane do pliku tymczasowego. W rzeczywistości nie wszystkie dane można zapisać w ten sposób.
ValueToFile(TempFileName, dane);

// Zapis tymczasowych danych do archiwum
Zip = New ZipFileEntry(TempArchiveFileName, Password,EncryptionMethod);
Zip.Add(nazwa_pliku tymczasowego);
Zip.Write();

// Wczytaj dane z otrzymanego archiwum do Baran
EncryptedData = NewValueStorage(New BinaryData(TempArchiveFileName));

// Pliki tymczasowe - usuń

EndFunction Funkcja DecryptData(EncryptedData, Password) Export

// Uwaga! Poprawność przekazywanych parametrów nie jest śledzona

// Zapisz przekazaną wartość do pliku
TempArchiveFileName = GetTemporaryFileName("zip");
BinaryArchiveData = EncryptedData.Get();
BinaryArchiveData.Write(TempArchiveFileName);

// Wypakuj pierwszy plik nowo napisanego archiwum
TempFileName = GetTempFileName();
Zip = NewReadZipFile(TempArchiveName, hasło);
Zip.Extract(Zip.Items, TemporaryFileName, FilePath Recovery ModeZIP.Don'tRecover);

// Przeczytaj zapisany plik
Dane = ValueFromFile(TempFileName + "\" + Zip.Elements.Name);

// Usuń pliki tymczasowe
DeleteFiles(TempFileName);
DeleteFiles(TempArchiveFileName);

Zwrot danych;

Funkcje końcowe

Oczywiście tej metody nie można nazwać idealną - dane są zapisywane do folderu tymczasowego czystym tekstem, wydajność metody, szczerze mówiąc, nie jest nigdzie gorsza, przechowywanie w bazie danych wymaga bardzo dużej ilości miejsca, ale to jest jedyna metoda oparta wyłącznie na wbudowanych mechanizmach platformy. Dodatkowo ma przewagę nad wieloma innymi metodami – metoda ta wykonuje pakowanie danych jednocześnie z szyfrowaniem. Jeśli chcesz zaimplementować szyfrowanie bez wad, które ma ta metoda, musisz albo zaimplementować je w komponencie zewnętrznym, albo odwołać się do istniejących bibliotek poprzez tworzenie obiektów COM, na przykład za pomocą Microsoft CryptoAPI. Jako przykład podajmy funkcje szyfrowania/odszyfrowywania ciągu znaków na podstawie otrzymanego hasła.

Funkcja EncryptStringDES(Niezaszyfrowany ciąg, hasło)

CAPICOM_ENCRYPTION_ALGORITHM_DES = 2; // Ta stała pochodzi z CryptoAPI

EncryptionMechanism.Content = zwykły ciąg;
EncryptionMechanism.Algorithm.Name = CAPICOM_ENCRYPTION_ALGORITHM_DES;
EncryptedString = EncryptionMechanism.Encrypt();

Zwróć zaszyfrowany ciąg;

EndFunction // EncryptStringDES()

Funkcja DecryptStringDES(EncryptedString, Password)

//Uwaga! Parametry nie są sprawdzane!

EncryptionMechanism = New COMObject("CAPICOM.EncryptedData");
EncryptionMechanism.SetSecret(hasło);
Próba
EncryptionMechanism.Decrypt(EncryptedString);
Wyjątek
// Niepoprawne hasło!;
Powrót Nieokreślony;
koniec próby;

Zwróć EncryptionMechanism.Content;

EndFunction // DecodeStringDES()

Należy o tym pamiętać przy przenoszeniu pusta wartość jako ciąg znaków lub hasło w tych funkcjach, zostanie wyświetlony komunikat o błędzie. Ciąg uzyskany przy użyciu tej procedury szyfrowania jest nieco dłuższy niż oryginał. Specyfika tego szyfrowania polega na tym, że jeśli zaszyfrujesz ciąg dwukrotnie, wynikowe ciągi NIE będą identyczne.

Główne błędy podczas korzystania z narzędzi kryptograficznych.

Podczas korzystania z narzędzi kryptograficznych często popełniane są te same błędy:

Niedoszacowanie spadku wydajności podczas korzystania z kryptografii.

Kryptografia to zadanie wymagające dość dużej ilości obliczeń (zwłaszcza dla algorytmów typu DES, 3DES, GOST, PGP). I nawet w przypadku zastosowania wysokowydajnych i zoptymalizowanych algorytmów (RC5, RC6, AES) nie ma ucieczki przed zbędnym transferem danych w pamięci i przetwarzaniem obliczeniowym. A to prawie neguje możliwości wielu komponentów serwera (macierze RAID, karty sieciowe). Podczas korzystania z szyfrowania sprzętowego lub wyprowadzania klucza sprzętowego do szyfrowania istnieje dodatkowe możliwe wąskie gardło wydajności: szybkość przesyłania danych między urządzeniem pomocniczym a pamięcią (a wydajność takiego urządzenia może nie odgrywać decydującej roli). W przypadku szyfrowania niewielkich ilości danych (na przykład wiadomości e-mail) wzrost obciążenia obliczeniowego systemu nie jest tak zauważalny, ale w przypadku całkowitego zaszyfrowania wszystkiego i wszystkiego może to znacznie wpłynąć na wydajność system jako całość.

Niedocenianie współczesnych możliwości doboru haseł i kluczy.

W tej chwili możliwości technologii są takie, że klucz o długości 40-48 bitów może wybrać mała organizacja, a klucz o długości 56-64 bitów – duża organizacja. Te. Należy stosować algorytmy wykorzystujące klucz o długości co najmniej 96 lub 128 bitów. Ale większość kluczy jest generowana przy użyciu algorytmów mieszających (SHA-1 itp.) na podstawie haseł wprowadzonych przez użytkownika. W takim przypadku klucz 1024-bitowy może również nie zostać zapisany. Po pierwsze, często używane jest łatwe do odgadnięcia hasło. Czynniki ułatwiające wybór to: użycie tylko jednego przypadku liter; używanie słów, nazw i wyrażeń w hasłach; wykorzystanie znanych dat, urodzin itp.; stosowanie „wzorców” podczas generowania haseł (na przykład 3 litery, następnie 2 cyfry, a następnie 3 litery w całej organizacji). Dobre hasło powinno być dość losową sekwencją liter, cyfr i znaków interpunkcyjnych. Hasła wprowadzane z klawiatury o długości do 7-8 znaków, nawet przy przestrzeganiu tych zasad, można odgadnąć w rozsądnym czasie, dlatego lepiej, aby hasło miało co najmniej 11-13 znaków. Idealnym rozwiązaniem jest odmowa generowania klucza za pomocą hasła, na przykład przy użyciu różnych kart inteligentnych itp., ale w tym przypadku konieczne jest zapewnienie możliwości zabezpieczenia się przed utratą nośnika klucza szyfrującego.

Niepewne przechowywanie kluczy i haseł.

Typowe przykłady tego błędu to:

• długie i skomplikowane hasła zapisane na naklejkach naklejanych na monitor użytkownika.
• przechowywanie wszystkich haseł w pliku, który nie jest chroniony (lub chroniony znacznie słabiej niż sam system)
• przechowywanie kluczy elektronicznych w domenie publicznej.
• częste przekazywanie kluczy elektronicznych pomiędzy użytkownikami.

Po co robić opancerzone drzwi, skoro klucz do nich leży pod dywanikiem przy drzwiach?

Przesyłanie początkowo zaszyfrowanych danych do niezabezpieczonego środowiska.

Organizując system bezpieczeństwa, upewnij się, że spełnia on swoje zadanie. Na przykład spotkałem się z sytuacją (niezwiązaną z 1C), kiedy początkowo zaszyfrowany plik, gdy program działał w otwartej formie, został umieszczony w folderze tymczasowym, skąd można go było bezpiecznie odczytać. Dość często kopie zapasowe zaszyfrowanych danych w postaci zwykłego tekstu znajdują się gdzieś „w pobliżu” tych danych.

Niewłaściwe użycie narzędzi kryptograficznych

Gdy przesyłane dane są szyfrowane, nie można oczekiwać, że nie będą one dostępne w miejscach, w których są wykorzystywane. Przykładowo usługi IPSec w żaden sposób nie uniemożliwiają „nasłuchiwania” ruchu sieciowego w warstwie aplikacji po stronie serwera aplikacji.

Dlatego, aby uniknąć błędów podczas wdrażania systemów kryptograficznych, przed ich wdrożeniem należy (co najmniej) wykonać następujące czynności.

• Dowiadywać się:
  • Co należy chronić?
  • Jaką metodę ochrony zastosować?
  • Które części systemu należy zabezpieczyć?
  • Kto będzie zarządzał dostępem?
  • Czy szyfrowanie będzie działać we wszystkich właściwych obszarach?
• Zdecyduj, gdzie informacje mają być przechowywane, w jaki sposób są przesyłane przez sieć oraz z jakich komputerów będą dostępne. Dostarczy to informacji o szybkości, pojemności i wykorzystaniu sieci przed wdrożeniem systemu, co jest przydatne do optymalizacji wydajności.
• Oceń podatność systemu na różnego rodzaju ataki.
• Opracuj i udokumentuj plan bezpieczeństwa systemu.
• Ocenić efektywność ekonomiczną (zasadność) stosowania systemu.

Wniosek

Oczywiście w pobieżnym przeglądzie nie sposób wskazać wszystkich aspektów związanych z bezpieczeństwem w 1C, ale wyciągnijmy kilka wstępnych wniosków. Oczywiście tej platformy nie można nazwać idealną - podobnie jak wiele innych ma własne problemy z organizacją bezpiecznego systemu. Ale to w żaden sposób nie oznacza, że ​​tych problemów nie da się ominąć, wręcz przeciwnie, prawie wszystkie niedociągnięcia można wyeliminować przy prawidłowym opracowaniu, wdrożeniu i użytkowaniu systemu. Większość problemów wynika z niedostatecznego opracowania konkretnego rozwiązania aplikacyjnego i środowiska jego wykonania. Na przykład typowe rozwiązania bez wprowadzania znaczących zmian po prostu nie oznaczają stworzenia wystarczająco bezpiecznego systemu.

Ten artykuł po raz kolejny pokazuje, że każdy zestaw środków bezpieczeństwa powinien obejmować wszystkie etapy wdrożenia: programowanie, wdrażanie, administrowanie systemem i oczywiście środki organizacyjne. W systemach informatycznych głównym zagrożeniem bezpieczeństwa jest „czynnik ludzki” (w tym użytkownicy). Ten zestaw środków powinien być rozsądny i wyważony: nie ma sensu i jest mało prawdopodobne, że zostaną przeznaczone wystarczające środki na organizację ochrony, która przekracza koszt samych danych.

Firma to wyjątkowa usługa dla kupujących, programistów, dealerów i partnerów stowarzyszonych. Ponadto jest to jeden z najlepszych internetowych sklepów z oprogramowaniem w Rosji, Ukrainie, Kazachstanie, który oferuje klientom szeroką gamę produktów, wiele metod płatności, szybkie (często natychmiastowe) przetwarzanie zamówień, śledzenie procesu realizacji zamówienia w sekcji osobistej.