Encrypt Your Data Assets

Build a flexible infrastructure to protect sensitive data.
John, the lead DBA at Acme Bank, is involved in a very important initiative regarding security and privacy. Jane, the chief information security officer of the company, has outlined Acme's security strategy, and John has identified his team's responsibilities.

Enterprise security, Jane explains at a meeting with IT managers at Acme, can be thought of as a series of protective layers. To illustrate her point, Jane uses a nesting doll—a doll with a hollow body inside which another hollow doll is kept, which, in turn, contains another hollow doll, and so on. The last of four or five of these hollow dolls contains some type of prize. Getting to the prize means removing the layers of the dolls one by one, and if the layers can't be removed for some reason, the prize becomes increasingly difficult to get to. To get to corporate information assets, Jane explains, an intruder must also defeat many layers of security.

The first layer of defense is the firewall around the whole information infrastructure of the organization, which keeps outsiders from accessing any of the information sources inside the company. However, no organization is an island and firewalls are far from airtight; "holes" or ports are necessary to let legitimate traffic from outside flow in.
If an intruder gets past the external firewall, that person will be required to supply a password to access the server or perhaps be asked to provide other authentication credentials such as security certificates. This is the next layer of security. After being authenticated, the legitimate user must be allowed to access only those assets that person is supposed to access. If a user gets into the database but has no authority to see any table, view, or any other data source, the information is still protected. This mechanism is the next layer of security.

Jane stresses that it is possible for an intruder to somehow defeat all of the protective measures and get to the enterprise data. From a planning perspective, this possibility must be accepted, analyzed, and accounted for. The only option left for defending against an intruder at this point, the last layer of security, is to alter the data, via a process known as encryption, in such a way that the intruder will not find it useful. Encryption alters data to make it unreadable to all except those who know how to decipher the information.

Database Encryption
When John leaves the IT managers' meeting, he immediately calls together his direct reports to talk about his team's encryption strategy and implementation.

He presents his take on the encryption strategy to his team, beginning with a brief overview of the encryption process. He presents a simple example in which the account balance value is altered by the addition of a secret one-digit number. If the secret number is 2, for example, and the real balance value is 3467, the encrypted value will be 3469. The real value can be deciphered from the encrypted value by the deduction of the number 2, a process known as decryption, John explains. This logic of adding a specific number to the real data is called the encryption algorithm. Here, the value 2, which is added by the algorithm, is known as the encryption key. Encrypting a value involves passing the original data and the encryption key to the encryption algorithm to create encrypted data.

During decryption, the logic is reversed, producing the original value. Because the same key is used to encrypt and decrypt, this scheme is also known as symmetric encryption.

Encryption algorithms are most often in the public domain; hence, the security lies in choosing a difficult-to-guess key. If hackers were to guess the 1-digit key, in this example, they would have to take only as many as 10 guesses—a number from 0 to 9. However, if the key were two digits, they would have to take as many as 100 guesses—a number from 0 to 99. The longer the key, John explains, the more difficult it is to guess it.

Oracle-Supplied Packages
In Oracle Database 10g, John continues, users can implement these encryption techniques by using functions and procedures available in a built-in package named DBMS_CRYPTO. Another package, DBMS_OBFUSCATION_TOOLKIT, also available in Oracle Database 10g and earlier releases, offers a subset of the functionality provided by DBMS_CRYPTO. But because Acme Bank's systems are built on Oracle Database 10g, the newer package offers more functionality, and Oracle recommends it over the older toolkit, John decides to use the DBMS_CRYPTO package, and no one in the room disagrees.

Key Generation. Because the security of the encrypted value depends on how hard it is to guess the key, using an appropriate key is a major step in the encryption process. A key can be any value of data type RAW, but unless it is random enough, an intruder will be able to guess the key. For instance, John warns, the key can't be something such as your pet's name or your date of birth; it must be truly random. "How do you generate such a random key?" asks one junior DBA. John answers that random values can be generated with the built-in package DBMS_RANDOM, but true cryptographically acceptable randomness means using the function RANDOMBYTES in the package DBMS_CRYPTO. This function accepts one parameter of data type BINARY_INTEGER and produces a RAW value of that length. This value can then be used as a key. John demonstrates the usage with a simple PL/SQL routine, shown in Listing 1.

Code Listing 1: Encrypting a value

  1  declare

  2     enc_val   raw (2000);

  3     l_key     raw (2000);

  4     l_key_len number := 128;

  5     l_mod     number := dbms_crypto.ENCRYPT_AES128

  6                       + dbms_crypto.CHAIN_CBC

  7                       + dbms_crypto.PAD_PKCS5;

  8  begin

  9     l_key   := dbms_crypto.randombytes (l_key_len);

10     enc_val := dbms_crypto.encrypt

11        (

12           UTL_I18N.STRING_TO_RAW ('SECRET', 'AL32UTF8'),

13           l_mod,

14           l_key

15        );

16      -- The encrypted value enc_val can be used here

 17  end;   

Explaining the code, John points out that the DBMS_CRYPTO package offers several types of algorithms and associated key lengths for Acme's encryption project.

The first column—Constant Name—shows the constant defined in the package to specify the different algorithms and the key length. For instance, to specify a 128-bit key according to the Advanced Encryption Standard (AES), you use the constant DBMS_CRYPTO.ENCRYPT_AES128, John expains. The longer the key, the less the chance that an intruder will be able to guess it but the more work the server has to do during encryption and decryption. To strike a balance between security and stress on the server, John chooses the middle ground—a 128-bit-key AES algorithm.
Next, the type of chaining, which divides the data into chunks to prepare for encryption in block ciphering, is defined, as shown in Listing 1, line 6. The most common format is Cipher Block Chaining (CBC), specified by a constant defined in the DBMS_CRYPTO package as CHAIN_CBC. Other chaining options include Electronic Code Book format (CHAIN_ECB), Cyber Feedback (CHAIN_CFB), and Output Feedback (CHAIN_OFB).

Finally, in block ciphering, John explains, the data is usually encrypted in blocks of eight characters. If the length of the input data is not a multiple of eight, you add a character or characters, in a process known as padding. A simple option is to use zeroes as padding. John points out that the constant PAD_ZERO defined in the DBMS_CRYPTO package pads with zeroes but that padding with zeroes is not considered very secure, because a potential intruder might be able to guess that. More-secure padding is based on Public-Key Cryptography Standards # 5 (PCKS#5), specified by the constant PKCS5 in the DBMS_CRYPTO package and demonstrated in Listing 1, line 7. If you're sure, John comments, that the length of the data is already a multiple of the block size, there is no need to pad, and you can specify that by using the constant PAD_NONE.

These three parameters—the algorithm with the key length, the chaining method, and the padding method—are all combined and passed to the built-in function ENCRYPT in DBMS_CRYPTO. The ENCRYPT function needs this input value to be a RAW data type. Listing 1, line 12 converts the input value to a RAW value, which is then passed to the ENCRYPT function.

As a means of standardization, John continues, Acme has made a decision to adopt the AES algorithm with 128-bit keys, CBC chaining, and PCKS #5 padding across all applications. Using these values, John builds a simpler function GET_ENC_VAL, shown in Listing 2, that accepts only two parameters—the input value and the key—and returns the encrypted value.

Code Listing 2: A simple encryption function

  1  create or replace function get_enc_val

  2  (

  3     p_in    in varchar2,

  4     p_key   in raw

  5  )

  6  return raw is

  7     l_enc_val raw (2000);

  8     l_mod     number := dbms_crypto.ENCRYPT_AES128

  9                      + dbms_crypto.CHAIN_CBC

10                      + dbms_crypto.PAD_PKCS5;

11  begin

12     l_enc_val := dbms_crypto.encrypt

13        (

14           UTL_I18N.STRING_TO_RAW

15              (p_in, 'AL32UTF8'),

16           l_mod,

17           p_key

18        );

19     return l_enc_val;

20* end;

Decryption
"When the time comes to decipher the encoded data, how do we do it?" asks Jill, one of John's developers.
John explains that DBMS_CRYPTO has a function for that too: DECRYPT. It accepts the source data to be decrypted; the key used during encryption; and the combined parameter of algorithm, key length, chaining, and padding schemes. The same key and the modifiers used during encryption must be passed along with the value to be decrypted. Because Acme Bank uses a standard algorithm, key length, and padding, John creates a simple function to decrypt encrypted values, as shown in Listing 3. This function accepts only two parameters—the encrypted value and the key—and returns the decrypted value as a VARCHAR2 data type. The conversion from the RAW data type is done in line 20 of Listing 3.

Code Listing 3: A simple decryption function

  1  create or replace function get_dec_val

  2  (

  3     p_in    in raw,

  4     p_key   in raw

  5  )

  6  return varchar2

  7  is

  8     l_ret     varchar2 (2000);

  9     l_dec_val raw (2000);

10     l_mod     number := dbms_crypto.ENCRYPT_AES128

11                       + dbms_crypto.CHAIN_CBC

12                       + dbms_crypto.PAD_PKCS5;

13  begin

14     l_dec_val := dbms_crypto.decrypt

15        (

16           p_in,

17           l_mod,

18           p_key

19        );

20        l_ret:= UTL_I18N.RAW_TO_CHAR

21                     (l_dec_val, 'AL32UTF8');

22             return l_ret;

23* end;

Key Management
With the building blocks in place, John's team is looking for a complete encryption solution built on the DBMS_CRYPTO package. The biggest challenge in encryption, John explains, is not generating keys or using the functions but managing the keys used in the encryption process. Because the same key is used to encrypt and decrypt a value, it must be reliably guarded to protect the data. At the same time, however, the applications and users must have access to the keys to decrypt the values for normal use. The challenge is figuring out where to store the keys and how to make sure they are available to legitimate users only, John explains. He lays out two options for managing keys:

1.     Use the same key for all records

2.     Use a different key for each record

With option 1, John continues, a single key is used to encrypt the value in all the rows. In this case, there are several options for storing the key:

• In the database—A key table owned by a special non-application owner can be used to store the key. John writes a simple function that merely returns the key as an output parameter. The users receive execute privileges in this procedure, and no user has any privileges on the key table. The function contains several checks and balances to make sure users have the proper privileges to get the key. Because the function is the only source for getting the key, users can be authenticated easily and given access to the key.
• In the filesystem—Keeping the key in the database protects from most intruders but not from DBAs who may have access to any table. In addition, making sure users making requests are indeed legitimate can be very difficult. Storing the key in a filesystem DBAs don't have access to, even on a different server such as an application server, may be a better idea. However, this also means that if the key is somehow lost because filesystems are damaged, the encrypted data is lost as well, forever.
• With the user—A third option, John shows, can be to let users keep the key somewhere, such as on a memory stick or a client machine. This way, no one other than legitimate users can access the sensitive data. This is particularly useful in situations such as in data warehouses where encrypted data is sent regularly to users who have the key already. If the data is stolen along the way, the sensitive information is still protected. However, the risk of data loss is highest here, because users are more likely to lose the key.

John proposes the "With the user" single-key solution for a small number of cases, such as publishing summarized content to various users who have received the keys earlier.

The biggest drawback of this approach is the vulnerability of the key to theft. If the key is stolen, all the data in the database is compromised. Therefore, John suggests a different approach to protecting sensitive data in OLTP databases. The database has a table named ACCOUNT_MASTER, where a sensitive data element, the account holder's name, is stored. The column containing the name, ACC_NAME, needs to be encrypted. The primary key of the table is ACCOUNT_NO. Here is what the ACCOUNT_MASTER table looks like:

SQL> desc account_master

Name        Null?     Type

----------  --------  ------------

ACCOUNT_NO  NOT NULL  NUMBER

ACC_NAME              VARCHAR2(200)

ACC_TYPE              CHAR(1)

John suggests using a different key for each row of the ACCOUNT_MASTER table, which eliminates the risk of databasewide exposure in case of a key theft. He creates a table called ACCOUNT_MASTER_ENC to store the encrypted values of the account name and creates another table to hold the keys used to encrypt the values. These tables—ACCOUNT_MASTER_ENC and ACCOUNT_MASTER_KEYS—look like this:

SQL> desc account_master_enc

Name           Null?     Type

------------   --------  --------    

ACCOUNT_NO     NOT NULL  NUMBER

ACC_NAME_ENC             RAW(2000)

SQL> desc account_master_keys

Name       Null?     Type

----------  --------  ---------  

ACCOUNT_NO  NOT NULL  NUMBER

KEY         NOT NULL  RAW(2000)

Next John creates the view VW_ACCOUNT_MASTER, shown in Listing 4, to join these three tables to get the decrypted value. He points out line 8 in Listing 4, where the value is decrypted with the function GET_DEC_VAL mentioned earlier. Because the function returns a value as a VARCHAR2 data type, it will be shown as a VARCHAR2(2000) column; hence, line 7 has a CAST function to make it a VARCHAR2(20) type.

This view, not the table, is what is granted to the other users. John creates a public synonym ACCOUNT_MASTER pointing to the view VW_ACCCOUNT_MASTER, not to the table of the same name.

Code Listing 4: View for account master

  1  create or replace view

  2     vw_account_master

  3  as

  4  select

  5     m.account_no as account_no,

  6     m.acc_type as acc_type,

  7     cast (

  8             get_dec_val (e.acc_name_enc, k.key)

  9     as varchar2(20)) as acc_name

10  from

11     account_master m,

12     account_master_enc e,

13     account_master_keys k

14  where

15     k.account_no = e.account_no

16*    and m.account_no = e.account_no; 

Because the public synonym ACCOUNT_MASTER points to the view, users can select from the view, but Jill the developer asks how the users will manipulate the data in the table. By using an INSTEAD OF trigger (shown in Listing 5), explains John. This trigger manipulates the data in the table whenever a user inserts or updates the view. The INSTEAD OF trigger fires when the data is either inserted or updated in the view, which, in turn, does an INSERT or UPDATE on the actual tables. While updating, it makes sure the encrypted values are also updated.

Code Listing 5: INSTEAD OF trigger on the view

  1  create or replace trigger io_vw_acc_master

  2  instead of insert or update on

  3  vw_account_master

  4  for each row

  5  declare

  6     l_key    raw(2000);

  7  begin

  8     if (inserting) then

  9        l_key := dbms_crypto.randombytes (128);

10        insert into account_master

11        (account_no, acc_type, acc_name)

12        values

13        (

14           :new.account_no,

15           :new.acc_type,

16           :new.acc_name

17        );

18        insert into account_master_enc

19        (account_no, acc_name_enc)

20        values

21        (

22           :new.account_no,

23           get_enc_val (

24              :new.acc_name,

25              l_key )

26        );

27        insert into account_master_keys

28        (account_no, key)

29        values

30        (

31           :new.account_no,

32           l_key

33        );

34     else

35        select key

36        into l_key

37        from account_master_keys

38        where account_no = :new.account_no;

39        update account_master

40        set acc_name = :new.acc_name,

41           acc_type = :new.acc_type

42        where account_no = :new.account_no;

43        update account_master_enc

44        set acc_name_enc =

45           get_enc_val (:new.acc_name, l_key)

46        where account_no = :new.account_no;

47     end if;

48* end;

Because the users can't see the data in the table but only through the view, the information is protected. A different view can be built on the base table to show only encrypted values, protecting the original contents.

Further Security
John then leads a discussion on refining the encryption key storage and access process even further. The group spends time discussing secure application contexts and how they will allow use of just one view that will behave differently for users of different authorization levels.

The meeting ends; John sends a quick e-mail to Jane, letting her know that the encryption plan is in place, and he offers to demonstrate it to her at her earliest convenience.

REFERENCES

Encrypt Your Data Assets By Arup Nanda

Efficient Space Management

Concepts of and sample questions on space usage

Oracle Database 10g provides a variety of features for managing the space usage of a tablespace. These features include the monitoring of tablespace usage, the ability to suspend transactions that require more space and successfully resume them when the space is available, and a database advisor that lets you determine whether an object has space available for reclamation.

This column presents sample questions on managing tablespace usage. The questions are of the type you may encounter when taking the Oracle Database 10g Administration Workshop II exam. The Oracle Database 10g Administration Workshop II exam is one of the two exams you must take to achieve the Oracle Certified Professional (OCP) level of certification. Note that the sample question format has been adjusted for presentation in this column.

Monitoring Tablespace Space Usage

Oracle Database 10g provides proactive help for managing the disk space usage of a tablespace. It alerts you when tablespaces run low on available space. Two space-used alert thresholds are defined by default: warning and critical. The warning threshold is the limit at which space starts to run low. The critical threshold is a serious limit that warrants your immediate attention. The database issues alerts at both thresholds.

You can modify the default threshold values and also disable the space-used threshold alerts for a tablespace.

You do not want to use the default threshold values for space used for the EXAMPLE tablespace. Which package would you use to explicitly set the space-used threshold values for a tablespace?

A. DBMS_SERVICE
B. DBMS_SERVER_ALERT
C. DBMS_STORAGE_MAP
D. DBMS_TRACE

The correct answer is B. You can use the SET_THRESHOLD procedure in the DBMS_SERVER_ALERT package to set the space-used threshold values for a particular tablespace. Alternatively, you can use Oracle Enterprise Manager 10g to set the space-used threshold values.

The USERS_TBS tablespace does not include autoextensible datafiles. Identify the situation in which server-managed threshold alerts for tablespace space usage will not be generated for the USERS_TBS tablespace.

A. If USERS_TBS is a bigfile tablespace
B. If USERS_TBS is the default permanent tablespace
C. If USERS_TBS is a temporary tablespace
D. If USERS_TBS is a dictionary-managed tablespace
E. If USERS_TBS is an UNDO tablespace

The correct answer is D. Server-managed threshold alerts for tablespace space usage are supported only for locally managed tablespaces, not for dictionary-managed tablespaces. Answers A, B, and C are incorrect because server-managed threshold alerts are supported for bigfile tablespaces, default permanent tablespaces, and temporary tablespaces. Answer E is incorrect because server-managed threshold alerts are supported for UNDO tablespaces.

You created a locally managed tablespace by using the following SQL statement:

CREATE TABLESPACE TEST_TBS

DATAFILE 'test.dat' SIZE 1M 

AUTOEXTEND ON MAXSIZE 100M;

You set the warning threshold limit to 60 percent for the TEST_TBS tablespace. Which statement is correct regarding the server-managed tablespace space usage threshold alerts in this scenario?

A. A warning alert will be generated when 60K of space is used.
B. No alerts will be generated, because it is not a bigfile tablespace.
C. No alerts will be generated, because the tablespace includes an autoextensible datafile.
D. A warning alert will be generated when 60MB of space is used.
E. A warning alert will be generated when 60MB of space is left as free space.

The correct answer is D. Answer A is incorrect because for tablespaces with autoextensible files, the thresholds are computed according to the maximum file size you specified or the maximum file size of the operating system. Answers B and C are incorrect because the alerts are generated for smallfile tablespaces as well as for tablespaces with autoextensible datafiles. Answer E is incorrect because the alerts are based on the space used and not on the free space left in a tablespace.

Resumable Space Allocation

In the event of space allocation failures, rather than returning the error to the user and stopping the operation, the transaction can be temporarily suspended and corrective action taken. After the error condition is corrected, the suspended operation automatically resumes. This feature is called resumable space allocation. The affected statements are called resumable statements.

Which two statements are correct regarding the resumable space allocation feature?

A. Resumable space allocation can be enabled only at the system level and not at the session level.
B. When a resumable statement is suspended, an error is reported in the alert log.
C. Every resumable operation has a "time out" period associated with it.
D. A resumable statement can be suspended and resumed only once during execution.

The correct answers are B and C. When the execution of a resumable statement is suspended, the system issues a Resumable Session Suspended alert. A suspended operation is automatically aborted if the error condition is not fixed within the time-out period. By default, the time-out period is two hours. Answer A is incorrect because you can enable resumable space allocation either at the system level, by setting the RESUMABLE_TIMEOUT initialization parameter to a nonzero value, or at the session level, by issuing the ALTER SESSION ENABLE RESUMABLE statement. Answer D is incorrect because a resumable statement can be suspended and resumed multiple times during execution.

Which statements are resumable? (Choose all that apply.)

A. INSERT INTO ... SELECT from external tables statement
B. CREATE TABLE ... AS SELECT statement
C. CREATE TABLESPACE statement
D. SELECT statement
E. CREATE USER statement

The correct answers are A, B, and D. DML statements, including INSERT INTO ... SELECT from external tables, are resumable. The interface used to execute the DML statements does not matter. DDL statements, including CREATE TABLE ... AS SELECT, are resumable. SELECT statements that run out of temporary space are also candidates for resumable execution.

Under which three error conditions can the resumable space allocation feature be used?

A. The user has exceeded his or her assigned space quota in the tablespace.
B. The number of extents in a table or index equals the number of maximum extents defined on the object.
C. The operation cannot acquire any more extents for an index in a tablespace.
D. The user application tries to access a table for which the user does not have necessary privileges.
E. The user-specified datafile size exceeded the maximum operating system file size.

The correct answers are A, B, and C. A resumable statement can be suspended under any of these conditions: space quota exceeded, maximum extents reached, and out of space.

Database Advisors

Oracle Database 10g provides a set of component advisors that provide useful feedback about resource utilization and performance. These advisors enable you to analyze the performance of your database, identify potential problems and bottlenecks, and tune the various components of your database.

DML operations on the objects within the USER_TBS tablespace have created pockets of empty space that individually are not big enough to be reused. This is leading to a large amount of wasted space in the USER_TBS tablespace. You plan to reclaim the wasted space through a shrink operation. Which advisor would you use to determine the objects in the USER_TBS tablespace that contain wasted space and are good candidates for the shrink operation?

A. SQL Tuning Advisor
B. Segment Advisor
C. Undo Advisor
D. SQL Access Advisor

The correct answer is B. You can use the Segment Advisor to determine whether an object has space available for reclamation on the basis of the level of space fragmentation within the object. The Segment Advisor can generate advice at three levels: object level (such as table), tablespace level, and segment level.

You can use the SQL Tuning Advisor for tuning SQL statements. The Undo Advisor improves transaction management, especially for automatic-undo management. The SQL Access Advisor provides recommendations for creating indexes and materialized views for a given workload.

Conclusion

You can use space-used threshold values to proactively manage the space in tablespaces. Space usage exceeding the threshold values raises alerts, allowing you to take action to ensure that there is space available. Resumable space allocation lets you suspend a statement temporarily, so that when more space is available, the transaction can resume and complete. The Segment Advisor—one of many database advisors—lets you identify unused space so that you can reclaim it.

REFERENCES

Efficient Space Management By Aradhana Puri

Network Storage - The Basics

Are you new to network storage? If so then this series of articles is for you! Over the next few months we are going to take a look at the basic principles of network storage and answer questions like 'What is network storage?' and 'Why do we use it?' After covering the basics, subsequent articles will look at specific technologies in more detail. All of the articles in the series will have one simple aim; to educate and inform you about network storage. So, without further ado, lets get to it!

In basic terms, network storage is simply about storing data using a method by which it can be made available to clients on the network. Over the years, the storage of data has evolved through various phases. This evolution has been driven partly by the changing ways in which we use technology, and in part by the exponential increase in the volume of data we need to store. It has also been driven by new technologies, which allow us to store and manage data in a more effective manner.

In the days of mainframes, data was stored physically separate from the actual processing unit, but was still only accessible through the processing units. As PC based servers became more commonplace, storage devices went 'inside the box' or in external boxes that were connected directly to the system. Each of these approaches was valid in its time, but as our need to store increasing volumes of data and our need to make it more accessible grew, other alternatives were needed. Enter network storage.

Network storage is a generic term used to describe network based data storage, but there are many technologies within it which all go to make the magic happen. Here is a rundown of some of the basic terminology that you might happen across when reading about network storage.

Direct Attached Storage (DAS)

Direct attached storage is the term used to describe a storage device that is directly attached to a host system. The simplest example of DAS is the internal hard drive of a server computer, though storage devices housed in an external box come under this banner as well. DAS is still, by far, the most common method of storing data for computer systems. Over the years, though, new technologies have emerged which work, if you'll excuse the pun, out of the box.

Network Attached Storage (NAS)

Network Attached Storage, or NAS, is a data storage mechanism that uses special devices connected directly to the network media. These devices are assigned an IP address and can then be accessed by clients via a server that acts as a gateway to the data, or in some cases allows the device to be accessed directly by the clients without an intermediary.

The beauty of the NAS structure is that it means that in an environment with many servers running different operating systems, storage of data can be centralized, as can the security, management, and backup of the data. An increasing number of companies already make use of NAS technology, if only with devices such as CD-ROM towers (stand-alone boxes that contain multiple CD-ROM drives) that are connected directly to the network.

Some of the big advantages of NAS include the expandability; need more storage space, add another NAS device and expand the available storage. NAS also bring an extra level of fault tolerance to the network. In a DAS environment, a server going down means that the data that that server holds is no longer available. With NAS, the data is still available on the network and accessible by clients. Fault tolerant measures such as RAID, which we'll discuss later), can be used to make sure that the NAS device does not become a point of failure.

Storage Area Network (SAN)

A SAN is a network of storage devices that are connected to each other and to a server, or cluster of servers, which act as an access point to the SAN. In some configurations a SAN is also connected to the network. SAN's use special switches as a mechanism to connect the devices. These switches, which look a lot like a normal Ethernet networking switch, act as the connectivity point for SAN's. Making it possible for devices to communicate with each other on a separate network brings with it many advantages. Consider, for instance, the ability to back up every piece of data on your network without having to 'pollute' the standard network infrastructure with gigabytes of data. This is just one of the advantages of a SAN which is making it a popular choice with companies today, and is a reason why it is forecast to become the data storage technology of choice in the coming years. According to research company IDC, SAN's will account for 70% of all network storage by 2004.

Irrespective of whether the network storage mechanism is DAS, NAS or SAN, there are certain technologies that you'll find in almost every case. The technologies that we are referring to are things like SCSI and RAID. For years SCSI has been providing a high speed, reliable method for data storage. Over the years, SCSI has evolved through many standards to the point where it is now the storage technology of choice. Related, but not reliant on SCSI, is RAID. RAID (Redundant Array of Independent Disks) is a series of standards which provide improved performance and/or fault tolerance for disk failures. Such protection is necessary as disks account for 50% of all hardware device failures on server systems. Like SCSI, RAID, or the technologies used to implement it, have evolved, developed and matured over the years.

In addition to these mainstays of storage technology, other technologies feature in our network storage picture. One of the most significant of these technologies is Fibre channel (yes, that that's fiber with an 're'). Fibre Channel is a technology used to interconnect storage devices allowing them to communicate at very high speeds (up to 10Gbps in future implementations). As well as being faster than more traditional storage technologies like SCSI, Fibre Channel also allows for devices to be connected over a much greater distance. In fact, Fibre Channel can be used up to six miles. This allows devices in a SAN to be placed in the most appropriate physical location.

Other developments are coming through that will change the way that we use and access network storage. One of these advances pegged to make a large contribution to the growing success of network storage in general is iSCSI. iSCSI is a technology that allows data to be transported to and from storage devices over an IP network. What it actually does is serialize the data from a SCSI connection. Using iSCSI, the concept of network storage can be taken anywhere that IP can go, which as the Internet proves, is basically anywhere. Technologies like Fibre Channel and iSCSI are a big factor in how fast people are able to afford and implement network storage solutions.

Over the coming months, we'll be taking a detailed look at all of the technologies that we have discussed in this introductory article. In our next article we'll start by taking a detailed look at perhaps the most significant element of today's network storage environment - SAN's. We'll also examine the devices used to create them. In addition, we'll be asking and answering the question 'How can a SAN benefit your business?' Stay tuned.

Many IT organizations today are scratching their heads debating whether the advantages of implementing a SAN solution justify the associated costs. Others are trying to get a handle on today's storage options and whether SAN is simply Network Attached Storage spelled backwards. In this article, I introduce the basic purpose and function of a SAN and examine its role in modern network environments. I also look at how SANs meet the network storage needs of today's organizations and answer the question, could a SAN be right for you.

Peel away the layers of even the most complex technologies and you are likely to find that they provide the most basic of functions. This is certainly true of storage area networks (SANs). Behind the acronyms and revolutionary headlines, lies a technology designed to provide a way of offering one of the oldest of network services, that of making access to data storage devices available to clients.

In very basic terms, a SAN can be anything from two servers on a network accessing a central pool of storage devices to several thousand servers accessing many millions of megabytes of storage. Conceptually, a SAN can be thought of as a separate network of storage devices physically removed from, but still connected to, the network. SANs evolved from the concept of taking storage devices, and therefore storage traffic, off the LAN and creating a separate back-end network designed specifically for data.

SANs represent the evolution of data storage technology to this point. Traditionally, on client server systems, data was stored on devices either inside or directly attached to the server. Next in the evolutionary scale came Network Attached Storage (NAS) which took the storage devices away from the server and connected them directly to the network. SANs take the principle one step further by allowing storage devices to exist on their own separate network and communicate directly with each other over very fast media. Users can gain access to these storage devices through server systems which are connected to both the LAN and the SAN.

This is in contrast to the use of a traditional LAN for providing a connection for server-storage, a strategy that limits overall network bandwidth. SANs address the bandwidth bottlenecks associated with LAN based server storage and the scalability limitations found with SCSI bus based implementations. SANs provide modular scalability, high-availability, increased fault tolerance and centralized storage management. These advantages have led to an increase in the popularity of SANs as they are quite simply better suited to address the data storage needs of today's data intensive network environments.

The advantages of SANs are numerous, but perhaps one of the best examples is that of the serverless backup (also commonly referred to as 3rd Party Copying). This system allows a disk storage device to copy data directly to a backup device across the high-speed links of the SAN without any intervention from a server. Data is kept on the SAN, which means the transfer does not pollute the LAN, and the server processing resources are still available to client systems.

SANs are most commonly implemented using a technology called Fibre channel (yes, that's fibre with an 're', not an 'er'). Fibre Channel is a set of communication standards developed by the American National Standards Institute (ANSI). These standards define a high-performance data communications technology that supports very fast data rates (over 2Gbps). Fibre channel can be used in a point-to-point configuration between two devices, in a 'ring' type model known as an arbitrated loop, and in a fabric model.

Devices on the SAN are normally connected together through a special kind of switch, called a Fibre Channel switch, which performs basically the same function as a switch on an Ethernet network, in that it acts as a connectivity point for the devices. Because Fibre channel is a switched technology, it is able to provide a dedicated path between the devices in the fabric so that they can utilize the entire bandwidth for the duration of the communication.

The storage devices are connected to Fibre Channel switch using either multimode or single mode fiber optic cable. Multimode for short distances (up to 2 kilometers), single mode for longer. In the storage devices themselves, special fiber channel interfaces provide the connectivity points. These interfaces can take the form of built in adapters, which are commonly found in storage subsystems designed for SANs, or can be interface cards much like a network card, which are installed into server systems.

So, the question that remains is this. Should you be moving away from your current storage strategy and towards a SAN? The answer is not a simple one. If you have the need to centralize or streamline your data storage then a SAN may be right for you. There is, of course, one barrier between you and storage heaven, and that's money. While SANs remain the domain of big business, the price tag's of SAN equipment is likely to remain at a level outside the reach of small or even medium sized businesses. As the prices fall, however, SANs will find their way into organizations of all sizes, including, if you want, yours.

REFERENCES

Network Storage - The Basics By Drew Bird