.:: strefa ::.

Microsoft udostępnił wersję Community Technology Preview (CTP) przydatnej aplikacji SQL Server 2005 Best Practices Analyzer. BPA nie jest produktem nowym - dostępny był dla wersji SQL Server 2000, nigdy jednak nie zyskał większej popularności. Best Practices Analyzer to narzędzie służące do analizy instancji, baz danych i usług pokrewnych SQL Server pod kątem m.in. bezpieczeństwa, ogólnej kondycji, wydajności. BPA generuje raport, w którym wymienione są wszelkie istotne uwagi wraz z podaniem rekomendowanych ustawień lub zalecanych działań. Dzięki raportowi można w łatwy, szybki i wygodny sposób zapoznać się z ogólną kondycją serwera i ewentualnie dokonać zmian konfiguracyjnych w określonych obszarach. Co prawda pewne rekomendacje są dość dyskusyjne, jednak nadal BPA jest godny polecenia - tego typu informacji nigdy za wiele.

Więcej informacji i pobieranie:
SQL Server 2005 Best Practices Analyzer (February 2007 CTP)

W zeszłym roku Microsoft przejął firmę Sysinternals, która dostarczała na rynek ciekawych i przydatnych aplikacji dla deweloperów i power users systemu Windows. Od wczoraj wszystkie narzędzia Sysinternals (pełna lista) dostępne są jako jeden pakiet (Sysinternals Suite - pobieranie). Polecam wszystkim, którzy używają systemu Windows do czegoś więcej niż gry czy przeglądanie internetu.

Zgodnie z porannymi plotkami Microsoft udostępnił długo oczekiwany Service Pack 2 dla wszystkich wersji SQL Server - także Express Edition (link poniżej). Lista zmian nie powala na kolana - choć zaznaczam, że jeszcze nie zapoznałem się z nią dokładnie. W każdym razie SP2 warto zainstalować choćby z tego powodu, że wprowadza możliwość generowania skryptów do wielu plików z poziomu aplikacji Management Studio :) Wraz z SP2 dostępna jest zaktualizowana wersja Books Online. Jutro przyjdzie czas przyjrzeć się nowemu SP bardziej dokładnie w warunkach środowisk testowych.

Więcej informacji i pobieranie:
SQL Server 2005 Service Pack 2

Pisałem ostatnio o zagadnieniach związanych z indeksami, gdzie m.in. starałem się uzasadnić potrzebę ich okresowej odbudowy. Oczywiście dokonywanie tego ręcznie - czy to poprzez interfejs Management Studio, czy przez polecenie ALTER INDEX .. REBUILD - jest delikatnie mówiąc mało praktyczne. Najczęściej wykorzystuje się do tego celu procedurę SQL, która z odpowiednią częstotliwością wywoływana jest z harmonogramu. Poniżej zamieszczam moją propozycję na tego typu procedurę:

Procedura reindeksacji (skrypt SQL z definicją) - proc_reindex.sql

Procedura odbuduje wszystkie indeksy w bazie danych o podanej nazwie, jeżeli ich poziom fragmentacji jest większy niż zadany.

Parametry:

@database_name [sysname] - nazwa bazy danych, w której ma odbyć się reindeksacja

@min_fragmentation_level [numeric(5,2)] - minimalny poziom fragmentacji, zakres 0-100.00;
domyślnie: 0 (wszystkie indeksy podlegają odbudowie - niezależnie od poziomu fragmentacji)

Opisywaną procedurę najlepiej utworzyć w bazie master - nie ma konieczności tworzenia jej we wszystkich bazach, w których ma odbywać się reindeksacja (procedura sama "przełączy" sobie kontekst). Zalecane jest uruchamianie procedury na prawach sysadmina (choć możliwe jest także selektywne dobranie odpowiedniego zestawu uprawnień na słabszym użytkowniku).

Przykładowe wywołania:

EXEC master..proc_reindex 'mojabaza'
EXEC master..proc_reindex 'mojabaza', 20

Procedura nie zadziała na SQL Server 2000.

Ogromna większość technologii programistycznych (języków programowania, języków skryptowych itp.) zakłada specyficzny sposób przetwarzania wyrażeń logicznych zawartych najczęściej w różnego typu instrukcjach warunkowych (IF, WHILE, FOR). Chodzi o to, że zdanie logiczne składające się z kilku wyrażeń, np:

A OR B OR C

jest uwzględniane tylko do momentu, w którym da się określić wartość całego wyrażenia. W powyższym przykładzie moment ten nastąpi już w sytuacji, w której wartość logiczna wyrażenia A będzie prawdziwa (alternatywa jest prawdziwa, gdy prawdziwy jest jeden z jej elementów). Głównym uzasadnieniem takiej obsługi są kwestie wydajnościowe i praktyczne. Opisane podejście do przetwarzania warunków ma jednak szereg konsekwencji, które warto sobie uświadomić. Postaram się zwrócić na nie uwagę bardziej szczegółowo prezentując implementację zasygnalizowanego zagadnienia w kilku środowiskach.

Practical Extraction and Report Language (Perl)

Spójrzmy na poniższy skrypt:

#!/usr/bin/perl

use strict;
use warnings;

my $count = 0;
my $a = 1;

if ($a != 1 and func() == 2) {

}

print $count;

sub func
{
   $count++;
   return 2;
}

Interesuje nas odpowiedź na pytanie, czy funkcja func() zostanie w ogóle wywołana. Otóż - zgodnie z tym, co napisałem we wstępie - nie zostanie. Nie ma potrzeby sprawdzania wyrażenia z funkcją, gdyż już na podstawie nieprawdziwości wyrażenia $a != 1 (1 != 1) można stwierdzić, że całe zdanie warunku jest fałszywe. Skrypt drukuje więc:

0

Trzeba o tym pamiętać umieszczając funkcję w logice instrukcji warunkowych.

W rzeczywistości to właśnie opisana obsługa warunków umożliwia stosowanie konstrukcji typu:

if (defined $zmienna and $zmienna == 5) { }

Gdyby za każdym razem przetwarzane było całe wyrażenie, to przy zastosowanym use warnings; dochodziłoby do monitu:

Use of uninitialized value in numeric eq (==) at (...)

zawsze wtedy, kiedy $zmienna byłaby undef.

Platforma .NET (C#)

Obsługa jest analogiczna, poniższy program drukuje 0.

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication1
{
   class Program
   {
      public static int count = 0;

      public static int func()
      {
         count++;
         return 2;
      }

      static void Main(string[] args)
      {
         int a = 1;

         if (a == 1 || func() == 2)
        {

         }

         System.Console.WriteLine(count);
      }
   }
}

Podobnie jak w Perlu, w C# (i innych językach .NETowskich) dzięki specyficznej obsłudze wyrażeń logicznych możliwe jest stosowanie konstrukcji:

if (obj != null && obj.property == 2) { }

Różnica między C# i Perlem polega jednak w tym przypadku na tym, że o ile w Perlu użycie niezainicjalizowanej zmiennej skutkuje co najwyżej ostrzeżeniem (warning level), o tyle w .NET użycie nieistniejącego obiektu kończy się rzuceniem wyjątku NullReferenceException().

C/C++

Przykładowy kod w przypadku C:

#include < stdio.h>

void main()
{
   int count = 0;
   int a = 1;

   if (a == 1 || func(&count) == 2) { }

   printf("%d", count);
}

int func(int* pcount) {
   (*pcount)++;
   return 2;
}

Jeżeli w powyższym kodzie pierwsze wyrażenie składowe warunku IF zostanie zmienione na 1 == 1, to większość kompilatorów w ogóle nie uwzględni drugiego wyrażenia alternatywy (z funkcją func()) - skompiluje więc warunek jako zawsze prawdziwy. Można się o tym łatwo przekonać zamieniając dodatkowo nazwę funkcji w warunku na taką, która nie istnieje:

if (1 == 1 || nie_mam_definicji(&count) == 2) { }

W obu przypadkach (zmieniony i niezmieniony kod przykładowy) skompilowany program zwraca 0.

JavaScript

Obsługa jest analogiczna:

<SCRIPT TYPE="text/javascript">

var count = 0;
var a = 1;

function func() {
   count++;
   return 2;
}

if (a == 1 || func() == 2) { }

alert(count);

</SCRIPT>

Alert prezentuje wartość 0.

Microsoft SQL Server

Jeżeli wywołamy poniższy T-SQL:

SELECT 0/0

SQL Server natychmiast rzuci błędem:

Msg 8134, Level 16, State 1, Line 1
Divide by zero error encountered.

Kiedy jednak dzielenie przez 0 znajdzie się w odpowiednim warunku logicznym:

IF (1=1 OR 1=0/0)
PRINT 'TRUE'

błąd nie występuje, gdyż nie dochodzi do wykonania wadliwego kodu.

O ile w przypadku Perla, C czy C# specyficzna ewaluacja warunków logicznych jest czymś pozytywnym, o tyle w świecie baz danych prowadzi do pewnych niekonsekwencji. Trzeba pamiętać, że SQL Server i inne RDBMS implementują logikę trójwartościową (three-valued logic, 3VL). Przestrzeń nie ogranicza się więc do wartości TRUE i FALSE, lecz składa się na nią TRUE, FALSE i UNKNOWN. Może więc dojść do sytuacji, że kiedy - ze względu na operację z NULLem - warunek powinien mieć wartość logiczną UNKNOWN, w praktyce zwraca wartość prawdy. Dokładnie taka sytuacja ma miejsce w poniższym przykładzie:

DECLARE @a int;
SET @a = 1;

IF (NOT (@a<>1 AND 1=NULL))
PRINT 'TRUE';

Warto o tym pamiętać, gdyż NULLe i stany nieokreśloności mogą generować sporą ilość trudno wykrywalnych problemów.

Sposób ewaluacji wyrażeń logicznych jest analogiczny w stosunku do wyżej opisanego w przypadku wszystkich znanych mi technologii (języków). Wiedza o takim sposobie obsługi jest więc całkiem wskazana tym bardziej, że umożliwi ona zapisywanie skomplikowanych warunków logicznych w sposób bardziej wydajny - czyli taki, aby sterując kolejnością wyrażeń składowych jak najwcześniej dało się zaprzeczyć lub uznać za prawdziwy cały warunek. Oczywiście ten swoisty tuning wyrażeń logicznych może mieć miejsce wyłącznie w środowisku, które respektuje kolejność wykonywania wyrażeń składowych zgodnie z ich występowaniem w kodzie (od lewej do prawej). Jest to powszechny standard, ale np. SQL Server się do niego nie stosuje.

Indeksy to podstawowy oręż w walce o wydajność zapytań, powszechnie określanej mianem optymalizacji. Każda broń najzwyczajniej w świecie zużywa się - podobna sytuacja ma miejsce w przypadku indeksów. Trzeba pamiętać, że proces optymalizacji zachodzi w każdym przypadku przetwarzania zapytania przez SQL Server - niezależnie od naszych intencji. Oczywiście możemy wiele wnieść do tego procesu, pisząc zapytania w sposób, który podsunie serwerowi najkorzystniejsze rozwiązanie zapytania - w końcu tylko my wiemy, co chcemy osiągnąć.

SQL Server query optimizer wykorzystuje estymację opartą na kosztach (cost-based optimization) w celu wyboru najkorzystniejszego planu wykonania zapytania (chodzi przede wszystkim o jak najmniejszą ilość operacji IO, ale nie jest to oczywiście jedyne kryterium). Optimizer naturalnie nie ma czarodziejskiej kuli - wszystkie obliczenia wykonuje na podstawie informacji o stanie danych i m.in. oceny aktualnego obciążenia. Z jego punktu widzenia celem jest jak najszybsze dostarczenie określonego przez zapytanie podzbioru rekordów.

Zakładając, że dane muszą być w odpowiedni sposób wybrane - optimizer jest zainteresowany tylko takimi operacjami, które najszybciej doprowadzą do selekcji żądanych rekordów ze zbioru źródłowego. SQL Server ma do wyboru kilka strategii: może patrzeć po kolei na poszczególne elementy zbioru (rekordy), dokonywać etapowo zawężeń lub łączyć obydwie techniki. Zawężenia wprowadzane są w oparciu o cechy (atrybuty) elementów zbioru, które okazują się maksymalnie selektywne. Ponadto potrzebna jest struktura, który szybko dostarczy informacji o tym, które elementy posiadają określoną cechę - w przeciwnym razie trzeba będzie przeglądać wszystkie po kolei. Jest to właśnie zadanie dla indeksu, który stanowi strukturę funkcjonalnie odpowiadającą spisowi treści dowolnej książki. Na podstawie zapytania SQL Server określa atrybuty zbioru (kolumny tabeli), które narzucone są w kryterium wyboru elementów (warunek WHERE, JOIN itd.). Wie także, jakie indeksy zostały utworzone. Musi podjąć decyzję, z których skorzystać, a z których korzystać się nie opłaca. Niewielki przecież pożytek z indeksu opartego na kolumnie, której wszystkie wartości są sobie równe albo niewiele jest elementów różniących się. Powiemy w takim przypadku, że kolumna ma małą selektywność (selectivity). Przykładowo: zerową selektywność ma wybór wszystkich czerwonych bil ze zbioru składającego się wyłącznie z czerwonych bil. Wielkością odwrotnie proporcjonalną do selektywności indeksu (kolumny) jest jego gęstość (density).

Gęstość to stosunek ilości wszystkich wartości kolumny (= wierszy) do liczby wartości unikalnych lub inaczej - to średnia liczba duplikatów wartości kolumny. Wielkość ta wyrażana jest jako procent lub ułamek o podstawie 100. Gęstość indeksu opartego na kolumnie, która w danej tabeli ze 100 wierszami ma wszystkie wartości unikalne wynosi 1%. Selektywność indeksu opartego na takiej kolumnie wynosi więc 100%. Jest naturalne, że im większa selektywność indeksu (kolumny), tym mniej odczytów trzeba wykonać, aby pobrać potrzebne dane (spis treści, który pozwala dotrzeć do informacji otwierając jedną czy dwie strony książki jest dużo efektywniejszy niż ten, za pomocą którego zawęzimy obszar poszukiwań np. tylko do rozdziału).

Oczywiście optimizer musi być w stanie oszacować aktualną przydatność indeksu przed jego ewentualnym zastosowaniem. Służą do tego statystyki indeksu (index statistics). Od razu wyjaśnię pewną nieścisłość pojęciową: co prawda powszechnie używa się terminu "statystyki indeksu", jednak w rzeczywistości statystyki dotyczą wyłącznie kolumny - i to nawet niekoniecznie indeksowanej. W praktyce dopuszczalny jest skrót myślowy polegający na tym, że mówiąc o wartościach indeksu, w rzeczywistości mówimy o wartościach kolumny, na której indeks jest zbudowany (sam indeks zasadniczo nie zawiera w sobie wartości kolumny, tylko referencje do nich przez wartości klucza głównego lub identyfikator wiersza - RID). Z tego punktu widzenia statystyki indeksu pojęciowo automatycznie odnosimy do statystyk kolumny.

Statystyki dostarczają informacji dotyczących rozkładu wartości w kolumnie. SQL Server tworzy w tym celu tzw. histogram. Odbywa się to w następujący sposób: najpierw ma miejsce sortowanie wartości kolumny i wybór do 200 elementów, które wyznaczają granice przedziałów. SQL Server określa następnie ile wartości przypada na każdy przedział, jaka jest jego gęstość i częstość występowania duplikatów. W zależności od typu danych kolumny, zbierane mogą być także inne informacje.

Bardzo ważną kwestią dotyczącą indeksów jest ich wewnętrzna i zewnętrzna fragmentacja (internal, external fragmentation). Nie będę tutaj dokładnie wyjaśniał na czym polegają te zjawiska, zainteresowanych odsyłam do zewnętrznych zasobów (linki poniżej). Istotne jest, że fragmentacja powstaje na skutek operacji DML na tabeli, kiedy logiczny porządek stron indeksu przestaje odpowiadać ich fizycznej kolejności. Wysoki poziom fragmentacji może uniemożliwić skuteczne użycie indeksu (samo odczytanie indeksu zacznie być dość kosztowne).

Z punktu widzenia powyższych rozważań dla skuteczności indeksu najistotniejsze są następujące kwestie:
- wysoka selektywność indeksu
- aktualność statystyk
- niski poziom fragmentacji

Pierwszy punkt dotyczy polityki zakładania indeksów. Temat jest bardzo szeroki i tutaj tylko go sygnalizuję (może w przyszłości coś o tym napiszę). Dwie pozostałe kwestie to już sfera bardziej techniczna. O stan indeksów musimy zadbać sami - inaczej urosną do dużych rozmiarów lub/i staną się nieefektywne. Mamy zasadniczo do wyboru trzy możliwości:

1. aktualizacja (update) statystyk
SQL Server 2000+2005: UPDATE STATISTICS, sp_updatestats

2. defragmentacja indeksu
SQL Server 2000: DBCC INDEXDEFRAG, SQL Server 2005: DBCC INDEXDEFRAG [deprecated], ALTER INDEX .. REORGANIZE

3. reindeksacja (odbudowa indeksu)
SQL Server 2000: DBCC REINDEX, SQL Server 2005: DBCC DBREINDEX [deprecated], ALTER INDEX .. REBUILD

Co do zasady im proces mniej inwazyjny, tym niestety mniej pożyteczny. Aktualizacja statystyk trwa dosłownie chwilę, ale nie poprawia struktury indeksu tylko sprawia, że optimizer dysponuje informacjami bardziej odpowiadającymi rzeczywistości. Defragmentacja indeksu z kolei nie gwarantuje pełnego usunięcia fragmentacji, ale ze względu na to, że w danym momencie zablokowane są tylko dwie strony danych - nie jest zbyt uciążliwa dla konkurujących procesów. Autor defragmentacji (Paul Randal) tak uzasadnił jej stworzenie:

"The main reason I wrote DBCC INDEXDEFRAG was to provide an online alternative to doing an index rebuild."

Doświadczyłem jednak już sytuacji przewlekłego zblokowania się defragmentacji i jednego z zapytań, więc mam bardziej krytyczne podejście do onlineowości tego procesu. Po defragmentacji należy we własnym zakresie zaktualizować statystyki. Reindeksjacja natomiast to w rzeczywistości pełna odbudowa indeksu (DROP + CREATE). Ma miejsce w jednej transakcji i blokuje daną tabelę na wyłączność na czas operacji (choć w wersji SQL Server 2005 Enterprise możne odbywać się także onlineowo). Zapewnia usunięcie wszystkich problemów związanym z pogarszaniem się stanu indeksów w drodze normalnej codziennej eksploatacji bazy. Po reindeksjacji nie ma potrzeby aktualizowania statystyk. Jestem zdania, że dla każdej bazy danych należy wyznaczyć czas na operacje maintenanceowe, które ze swej natury wymagają niekiedy trybu offline.

Oddzielnym zagadnieniem jest defragmentacja wolumenu, na którym znajdują się pliki baz danych. Jej sensowność bywa często kwestionowana (zwłaszcza przez osoby średnio orientujące się w temacie). Prawda jest jednak taka, że defragmentacja wolumenu przynosi poprawę wydajności bazy, zwykle jednak nie jest ona monumentalna. Z moich doświadczeń mogę powiedzieć, że po defragmentacji wolumenu zapytania wykonywały się zwykle około 5-7% szybciej (macierz RAID 1). Ze względu na problematyczność i uciążliwość tego typu operacji (choć zaznaczam, że nie musi to być operacja w trybie offline), administratorzy często nie decydują się na włączanie defragmentacji do polityki utrzymaniowej bazy.

Więcej informacji:
SQL Server Performance: SQL Server Index Fragmentation and Its Resolution
MSDN: Index Statistics
SQL Server 2005 Books Online: Understanding Indexes

W dzisiejszym świecie ochrona informacji przed niepowołanym dostępem staje się tematem coraz bardziej doniosłym. Twórcy oprogramowania oczywiście dostrzegają ten trend, oferując całkiem spory i różnorodny wachlarz rozwiązań z tego zakresu. Sprawne poruszanie się w tematyce bezpieczeństwa systemów komputerowych, ochrony informacji, kryptografii itp. wymaga posiadania ugruntowanej wiedzy - co często powoduje, że osoby nie związane zawodowo z security rezygnują z tego typu nowinek. Jak postaram się niżej pokazać - rezygnacja ta nie jest wcale konieczna.

Chciałbym zaprezentować jedną konkretną aplikację, która ze względu na szereg cech wydaje mi się najbardziej godną uwagi propozycją dla osób o różnym zaawansowaniu (zwykli użytkownicy, power users, administratorzy) zainteresowanych możliwością realnego zabezpieczenia poufnych danych. Chodzi o opensource'owy program TrueCrypt (linki do strony domowej poniżej), który dostępny jest w wersjach zarówno pod Microsoft Windows, jak i Linux. TrueCrypt należy do gatunku aplikacji szyfrujących dane w locie (on-the-fly encryption). Program tworzy specjalny wirtualny dysk (virtual encrypted disk), na którym wszystkie dane przechowywane są w postaci zaszyfrowanej. Wolumen taki - po zamontowaniu przez TrueCrypt - jest przez system widziany jak każda inna jawna partycja. Pracujący w tray'u TrueCrypt pośredniczy w wymianie danych między zaszyfrowaną partycją a systemem operacyjnym - szyfrując lub deszyfrując dane w zależności od kierunku komunikacji. Całość operacji kryptograficznych odbywa się na bieżąco w pamięci RAM.

Zaszyfrowane wirtualne dyski to w rzeczywistości albo standardowe pliki w systemie plików (z niestandardową zawartością), albo pełnowartościowe partycje dyskowe. W pierwszym przypadku TrueCrypt montuje wirtualną partycję z zaszyfrowanej zawartości pliku, w drugim - z fizycznej partycji zawierającej specjalną strukturę z zaszyfrowanymi danymi. W przypadku ostatnim pewnym problemem jest fakt, że system operacyjny widzi dwie partycje - zaszyfrowaną i odszyfrowaną (zamontowaną przez TrueCrypt). O ile w przypadku odszyfrowanej nie ma problemów z interpretacją systemu plików, o tyle partycja zaszyfrowana jest dla systemu operacyjnego zupełnie niezrozumiała i prawdopodobnie będziemy zasypywani propozycjami jej formatowania (opracowano oczywiście pewne środki zaradcze, aby sytuacja nie była uciążliwa).

Z punktu widzenia użytkownika najistotniejszym momentem całej układanki jest montowanie wirtualnego dysku z zaszyfrowanego źródła (np. plikowego). Do wykonania tej operacji TrueCrypt wymaga podania dedykowanego hasła montowania ustalonego podczas tworzenia zaszyfrowanego wolumenu.

Podczas tworzenie zaszyfrowanego wolumenu użytkownik konfiguruje typ kontenera (plikowy vs partycja dyskowa), rozmiar, system plików - jaki ma naśladować zamontowany wirtualny dysk (NTFS, FAT), wybierany jest także algorytm szyfrujący i algorytm funkcji skrótu. Mamy do dyspozycji najmocniejsze i najszybsze algorytmy szyfrujące:
- AES
- Blowfish
- CAST5
- Serpent
- Triple DES
- Twofish
- Cascades

oraz algorytmy hashujące:
- Whirlpool
- RIPEMD-160
- SHA-1

Program umożliwia automatyczne przetestowanie wszystkich algorytmów w danym systemie pod kątem wydajności - łatwo możemy więc wybrać np. najszybszy z dostępnych. Oczywiście procesy szyfrowania/deszyfrowania należą do ciężkich obliczeniowo, ale na stosunkowo nowej maszynie opóźnienia z tym związane są dla przeciętnego użytkownika praktycznie niezauważalne.

Autorzy TrueCrypt opracowali i zaimplementowali dodatkowo bardzo ciekawą funkcjonalność, tzw. ukryty wolumen (hidden volume). Doszli do wniosku, że w niektórych sytuacjach właściciel zaszyfrowanych danych może zostać zmuszony do ujawnienia hasła montowania (np. poprzez zastosowanie przemocy fizycznej). Możliwe jest więc tworzenie zaszyfrowanego wolumenu w innym zaszyfrowanym wolumenie. Pierwszy (wewnętrzny) przechowuje dane, które użytkownik rzeczywiście chce ukryć. Zajmuje on wolny obszar wolumenu drugiego (zewnętrznego). Aby rozwiązanie miało sens, obydwa magazyny muszą mieć różne hasła montowania. W wolumenie zewnętrznym zaleca się umieścić dane wyglądające na ważne i poufne. W sytuacji kryzysowej ujawnione zostanie tylko hasło montowania do wolumenu zewnętrznego. Istnienie wolumenu wewnętrznego jest niewykrywalne nawet po zamontowaniu wolumenu zewnętrznego, gdyż każdy magazyn podczas tworzenia w całości wypełniany jest losowymi danymi. Utrata poufności dotknie więc tylko dane "podstawione" - tym samym realnie chronione informacje mają dużo większą szanse pozostania nieujawnionymi.

Myślę, że zagłębianie się w szczegóły implementacyjne byłoby tutaj bezcelowe, acz warto podkreślić, że autorzy mieli szereg bardzo ciekawych i skutecznych pomysłów. Wykorzystali również sprawdzone rozwiązania opracowane wcześniej (choćby generator praktycznie silnych liczb losowych Petera Gutmanna). Wszystkie szczegóły wraz z kodem źródłowym i dokumentacją techniczną dostępne są na stronie projektu. Na pochwałę zasługuje też bardzo intuicyjne i wygodne GUI. Nic więc dziwnego, że TrueCrypt może się pochwalić wierną rzeszą entuzjastów. Warto też zaznaczyć, że zaszyfrowane wolumeny TrueCrypt są całkowicie cross-platformowe.

Oczywiście prezentowane przeze mnie rozwiązanie ma pewne słabości. Można tu wskazać problem incydentalnego zapisu niezaszyfrowanych poufnych danych do pliku stron - choć w tym przypadku da się zagrożenie wyeliminować przez włączenie opcji no paging file w systemie Windows. Problemem może być także hibernacja czy np. informacje o montowanych partycjach zapisane przez system w rejestrze. Nie są to duże issues i według mnie finalna analiza zagrożeń wypada dla TrueCrypt bardzo korzystnie. Należy jednak pamiętać, że przecież nie ma zabezpieczenie idealnego.

Więcej informacji:
TrueCrypt - strona domowa