Gizlilik ve Bütünlük Nasıl Korunur?

 

 TLS ve HTTPS kullanarak, kaynakları yalnızca isteklere hizmet edecek şekilde yapılandırılmış bir sunucu üzerinden erişilebilir hale getirin.  HTTP katmanlı bir protokoldür. Mesaj aktarım güvenliği TCP /IP aktarım protokolüne dayanır. TLS (RFC 5246) pro üzerinden HTTP katmanlayarak SSL'in halefi olan tocol gizliği ve bütünlüğü koruyabilinir.  Şifreleme ve dijital imza ile uğraşmadan istek ve yanıtlar mesajların istemci ve sunucu kodundaki türlerini kapsar.

 

TLS  her iki sunucuda da karşılıklı kimlik doğrulama için kullanılabilir.  Kullanıcıların kimlik doğrulaması için temel kimlik doğrulamasını TLS güvenerek kullanılabilir.  TLS gizlilik ve bütünlük için kullandığınızda, protokol oluşturmaktan kaçınabilirsiniz. Bu tür güvenlik önlemleri için doğrudan istek ve yanıt mesajları ve dahası TLS mesajdan bağımsızdır. Herhangi bir medya türü veya talebi için kullanılabilir.

SOAP tabanlı web hizmetlerinin WS-Security'ye güvenli göndermenin yollarını belirtir. SOAP başlıklı belirteçler, örneğin kurcalamayı önlemek için SOAP tabanlı web hizmetleri SOAP mesajlarının başlığına aşağıdaki örnekteki gibi imza ekler.

# A SOAP message containing a signature

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

   <soapenv:Header>

      <wsse:Security

         soapenv:actor="http://www.example.org"

         soapenv:mustUnderstand="1"

         xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">

         <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

            <SignedInfo>

               <CanonicalizationMethod

                  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

               <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

               <Reference URI="#abcd">

                  <Transforms>

                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

                  </Transforms>

                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

                  <DigestValue>... digest value</DigestValue>

               </Reference>

            </SignedInfo>

            <SignatureValue>...</SignatureValue>

            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

               ... key info ...

            </KeyInfo>

         </Signature>

      </wsse:Security>

   </soapenv:Header>

   <soapenv:Body>... application data ...</</soapenv:Body>

</soapenv:Envelope>

Bu mesaj Body öğesindeki uygulaa verilerini ve bunun imzasını içerir. Üstbilgi Bunun aksine RESTful web hizmetleri HTTPS kullanabilir. (TLS üzerinden  HTTP katmanlandırılmış) TLS in yöntemlerden bağımsız olarak dijital imzalar ve şifreleme ile ilgilenmesine izin vermek için kullanılan ortam türleri için.

HTTP nin katmanlı mimarisi uygulama düzeyindeki mesajları taşıma düzeyinde güvenlikten dolayı ayırır.

URL lerdeki Hasas Bilgiler

 

  URL üzerindeki verilerin kurcalandığını algılamak için algoritmaları kullanarak URL üzerindeki verilerin dijital imzasını hesaplayabiliriz. HMAC-SHA1 ve RSA-SHA1 gibi. URL kaynağına imzayı bir sorgu parametresi gibi eklemek.

URL lerdeki veriler gizliyse AES, Blowfish veri algoritmalarını şifreleyin. DES, Triple DES, Serpent, Twofish v.b URL dahil olan sonucu Base64 olarak kodladığınızdan emin olun.

Örnekte; Sigorta teklif örneğinde; sunucu gösterimindeki bir bağlantıda bir alıntı yayınlamak için kullanılan verileri kodlar.  Teklife göre sigorta satın almak için bağlantıyı kullanır.

# Request

GET /quotegen?fname=...&lname=...&... HTTP/1.1

Host: www.example.org

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset=UTF-8

<quote xmlns:atom="http://www.w3.org/2005/Atom">

   <driver>

      ...

   </driver>

   <vehicle>

      ...

   </vehicle>

   <offer>

      ...

      <valid-until>2009-08-02</valid-until>

      <atom:link href="http://www.example.org/quotes/buy?fname=...&lname=...&..."

               rel="http://www.example.org/quotes/buy"/>

   </offer>

</quote>

Bağlantıda kullanılan URL deki kodlanan durum kurcalamaya eğimlidir. Bunu önlemek için sunucu teklif oluşturmak için kullanılan tüm önemli parametrelerin imzasını içerebilir.

http://www.example.org/quotes/buy?fname=...&lname=...&...&sign=f5b244520c2a452a0ee8c8b6ab5b6828317d2f7f

Bu örnekteki imza HMAC-SHA1 ve bilinen bir imza kullanılarak hesaplanmıştır. İstemci bir talep de bulunduğunda sunucu imzayı yeniden hesaplar, URL dahil edilen verilerin bir kısmı ve URL de bulunan imza ile karşılaştırın. Bu değer arasındaki herhangi bir fark verilerin tahrif edildiğini gösterir.

Sunucu bunun yerine durumu şifreleyebilir ve şifreli durumu kullanabilir.

http://www.example.org/quotes/buy?gZwEW9oJIlZhYa1CuJ9IshGyvYJp2Gfo99M5115

hWRKk497mkAOrnBZhkSb18UBzYftLpnryxUT2Y0C8GFDpNT64hypV4kMu

TLS kullanmak bir seçenek olmadığında; sunucu istemcinin gövdeyi eklemesini isteyebilir. İmzadaki talebin durumunda, sunucunun bir tanımlayıcı ataması ve her müşteri için paylaşılan bir  imza ve müşterinin kullanması gereken algoritmayı belgelendiren imzalar oluşturur. Örnek; OAuth istekleri için şunlar içerir.

* Talebin gövdesinde yer alan herhangi bir parametrenin imzası;

* Özet kimlik doğrulaması qop=auth-int ile birlikte; isteğin gövdesini de özetin bir parçası olarak kullanır.

Her iki yaklaşımda talebin bütünlüğünü sağlar.

Üç Aşamalı OAuth Kullanımı

 3 aşamalı denmesinin nedeni ise Servis sağlayıcı (sunucu), OAuth tüketicisi (müşteri), Kullanıcı bulunur.

Protokolün başlangıcında; Sunucu tarafında müşteri için bir tanımlayıcı olarak "tüketici anahtarı" ve paylaşılan gizli "tüketici sırrı" kullanılır. Bir kullanıcı istemciye kaynaklara erişim yetkisi verdiğinde, sunucu bir tanımlayıcı olarak erişim token yetkili olan istemciyle gizli olarak paylaşır.

OAuth sunucu tarafında istemciye verilen 3 token sırrına dayanır.

Tüketici anahtarı ve tüketici sırrı:

Tüketici anahtarı  müşteri için benzersiz bir tanımlayıcıdır. Müşteri gizli istek belirteçleri alma taleplerini imzalamak için tüketiciyi kullanır.

Token ve Token Sırrı:

Token isteği sunucu tarafında bir defa olarak geçici tanımlayıcıdır. Kullanıcıdan istemciye izin vermesini istemenin amacıdır.

Token Sırrı; erişim belirteci alma taleplerini imzalamak için kullanılır.

Giriş Tokeni ve Token Sırrı:

Giriş Tokeni: İstemcinin kullanıcının kaynaklarına erişmek için kullanacağı tanımlayıcıdır. Giriş tokenine sahip bir müşteri kullanıcının kaynaklarına erişir. Sunucu süresinin dolması nedeniyle istediği zaman  erişimi iptal edebilir.

Token Sırrı; erişim isteklerinin imzalanmasında kullanılır. Kullanıcının kaynaklarının korunması sebebi ile kullanılır.

OAuth yönetiminin kullanılması aşağıdaki adımları içerir. Bu akışın amacı; bir token ve token anahtarı elde edilmesi, Sunucu için bir giriş belirteci yaratılması, zaman dilimi ile belirli kullanıcı kaynaklarına erişim sınırlaması.

1- İstemci, sunucudan bir tüketici anahtarı ve token sırrı ister.

2- Müşteri bir talep belirteci ve token sırrı almak için tüketici anahtarını kullanır. 

3-İstemci, erişime izin verebilmek için kullanıcıyı sunucuya yönlendirir. Bu işlem kimliği doğrulanmış bir istek belirteci ile sonuçlanır.

4- İstmeci, sunucudan bir erişim belirteci ve sır vermesini ister, Müşterinin kaynaklara erişmek için kullanabileceği bir tanımlayıcı ve token sırrı olarak temsil edilir.

5- İstemci, korumalı bir kaynağa erişim talebinde bulunurken; bir yetkilendirme sorgulama parametreleri tüketici anahtarını, giriş belirteci , imza yöntemi, imza, zaman damgası, tek seferlik isteği bağlı olarak OAuth protokolü sürümü.

OAuth, HTTP üzerine yerleştirilmiş bir protokol olduğundan sunucuların istemcilere aşağıdaki URI;

* İstek belirteci almak için URI;

* Sunucu yetkilendirme için URI;

* Erişim belirteci almak için URI;

OAuth, istek ve erişim belirteçlerini almak için POST kullanması önerir.

Fotograf albümü veren bir web hizmetinde; Müşterinin ihtiyacı olan kullanıcı fotograf albümü kaynağının bir kopyasını oluşturabilmesi için yetkilendirme söz konusudur. İstemci bir oauth_consumer_key ve gizli anahtar almak için sunucuya gider. Örneğin sunucu istemciler için bir web sayfası sağlayabilir. Tüketici tarafından oluşan anahtar ve gizli token için.  Tüketici anahtarı : a1191fd420e0164c2f9aeac32ed35d23 ve gizli token : fd9b9d0f769c3bcc548496e4b5077da79c02d7be.

İstemcinin 3 adımlı protokolü başlatması için Sunucu; aşağıdaki URI;

* İstek belirteçlerini almak için https://www.example.org/oauth/request_token

* Kullanıcı yetkilendirmesi almak için https://www.example.org/oauth/authorize

* Erişim belirteci almak için https://www.example.org/oauth/access_token

Not: Yanıtlar paylaşılan dizi içerdiğinden TLS kullanın, kullanıcı yetkilendirmesi ve shared secret;

İstekler aşağıdaki parametleri içerir. 

oauth_consumer_key: Sunucu tarafından her istemciye verilen benzersiz bir tanımlayıcıdır.

oauth_signature_method : İmza hesaplanırken kullanılan imzalama yöntemidir. OAuth, HMAC tanımlar. İmzalana yöntemleri olarak; SHA1 ve RSA-SHA1. İstemci ve sunucular arasından TLS kullanıldığından imzalardan kaçınabilirsiniz ve bu parametrenin değierini PLAINTEXT kullanabilirsiniz.

oauth_timestamp : January 1, 1970, 00:00:00 GMT. itibaren geçen saniye sayısına eşittir.

oauth_nonce : Belirli bir zamanda gönderilen tüm istekler için benzersiz rastgele dizedir.

oauth_timestamp: Sunucuların yeniden ataklara karşı korunmasında yardımcı olur. Benzersiz özet kimlik doğrulaması gibi. OAuth istemcikerin nonce değeri oluşturması gerekir.

oauth_version: OAuth sürümüdür.

İstemci ilk adım olarak istek belirteci ve bir secret key almak için bir istek gönderir. Sunucu bu talepde yer alan imza , tüketici gizli anahtarına dayanmaktadır. Müşteri tüketici anahtarı ile birlikte elde edilir. İmza aşağıdakilerini içerir.

oauth_consumer_key, oauth_signature_method, oauth_timestamp, oauth_nonce, ve oauth_version

1- Parametreleri Toplayın;

oauth_consumer_key,

oauth_timestamp, oauth_nonce, and oauth_version.

2-Parametleri yüzde olarak kodlayın önce adlarına göre sonra değerlerine göre;

3-Hazırlanan parametreleri bir dizeye yerleştirin. Örnek;

oauth_con

sumer_key=a1191fd420e0164c2f9aeac32ed35d23&oauth_nonce=109843dea839120a&oa

uth_signature_method=HMAC-SHA1&oauth_timestamp=1258308730&oauth_ver

sion=1.0.

4- Paylaşılan token anahtarı kullanarak bir imza hesaplama: Örnek;

d8e19bb988110380a72f6ca33b2ba5903272fe1.

5-İmzayı Base64 olarak kodlayın ve ardından elde edilen metni yüzde olarak kodlayın.

 İmzayı kullanan tüketici bir talep belirteci almak için bir talep gönderir.

Örnek;

# Request to obtain a request token

POST /request_token HTTP/1.1

Host: www.example.org

Authorization: OAuth realm="http://www.example.com/photos",

oauth_consumer_key=a1191fd420e0164c2f9aeac32ed35d23,

oauth_nonce=109843dea839120a,

oauth_signature=d8e19bb988110380a72f6ca33b2ba5903272fe1,

oauth_signature_method=HMAC-SHA1,

oauth_timestamp=1258308730,

oauth_version=1.0

# Response containing a request token and a secret

HTTP/1.1 200 OK

Content-Type: application/x-www-form-urlencoded

oauth_token=0e713d524f290676de8aff4073b1bb52e37f065c

&oauth_token_secret=394bc633d4c93f79aa0539fd554937760f05987c

POST /request_token HTTP/1.1 > İstek belirteci ve sırrı alma talebi

oauth_nonce=109843dea839120a,

oauth_signature=d8e19bb988110380a72f6ca33b2ba5903272fe1,

oauth_signature_method=HMAC-SHA1,

oauth_timestamp=1258308730,

oauth_version=1.0 > istemcinin kimliğini doğrulamak için yetkilendirme başlığı

oauth_token=0e713d524f290676de8aff4073b1bb52e37f065c

&oauth_token_secret=394bc633d4c93f79aa0539fd554937760f05987c 

> Bir istek belirteci ve sırrı içeren yanıt.

oauth_token yanıt istemcinin bunu yapmak için kullanması gereken bir istek belirtecidir. İstemci kullanıcıyı sunucudaki bir kaynağı ziyaret etmeye ve yetki vermeye yönlendirir.

Yetki Alma Talebi:

# Request to obtain authorization

GET /oauth/authorize?oauth_token=0e713d524f290676de8aff4073b1bb52e37f065c HTTP/1.1

Host: www.example.org

Bu kaynağın uygulanması sunucuya bağlıdır. Bu noktada sunucu kullanıcının sunucuya kimlik doğrulama yapıp yapmadığını kontrol etmemiz gerekir. 

İstemci bir erişim belirteci almak için doğrulama kodu kullanır. Bunun içerisindeki imza isteği; 

oauth_signature_method, oauth_timestamp, oauth_nonce, and oauth_version

# Request to obtain an access token

POST /access_token HTTP/1.1

Host: www.example.org

Authorization: OAuth oauth_consumer_key="a1191fd420e0164c2f9aeac32ed35d23",

                               oauth_token="ad0d1c7a765c9e6e8b14e639c763177312d18e7e",

                               oauth_verifier="988786765423",

                               oauth_signature_method="RSA-SHA1",

                              oauth_signature="698d58fd3316304181e11c6eb8127ffea7e2df46",

                               oauth_timestamp="1258328458",

                               oauth_nonce="109843dea839120a",

oauth_version="1.0"

Content-Length: 0

HTTP/1.1 200 OK

Content-Type: application/x-www-form-urlencoded

oauth_token=8d743f1165c7030177040ec70f16df8bc6f415c7

&oauth_token_secret=95aec3132c167ec2df818770dfbdbd0a8b2e105e

POST /access_token HTTP/1.1 > Erişim belirteci ve secret key alma isteği

Authorization: OAuth oauth_consumer_key="a1191fd420e0164c2f9aeac32ed35d23",

oauth_token="ad0d1c7a765c9e6e8b14e639c763177312d18e7e",

oauth_verifier="988786765423",

oauth_signature_method="RSA-SHA1",

oauth_signature="698d58fd3316304181e11c6eb8127ffea7e2df46",

oauth_timestamp="1258328458",

oauth_nonce="109843dea839120a",

oauth_version="1.0"

> İstemcinin kimliğini doğrulamak için yetkilendirme başlığı

oauth_token=8d743f1165c7030177040ec70f16df8bc6f415c7

&oauth_token_secret=95aec3132c167ec2df818770dfbdbd0a8b2e105e

 > Erişim token ve secret key içeriği

Bu yanıt erişim belirteci  ve secret token anahtarı içerir. Sunucunun istek belirteci için bir erişim belirteci vermeden önce tüketici anahtarı ile eşleşmesini sağlar.

İstemci isteklerle bir Yetkilendirme başlığı oluşturmak için kullanıcı için korumalı kaynaklara erişim için; 

oauth_consumer_key, access token, oauth_signature_method, oauth_timestamp,

oauth_nonce, and oauth_version değerlerini kullanır. İstek ortam türü olduğunda istek  gövdesine application/x-www-form-urlencoded kullanır.

# Request

POST /albums/2009/08/1011/duplicate;t=a5d0e32ddff373df1b3351e53fc6ffb1 HTTP/1.1

Host: www.example.org

Authorization: OAuth oauth_consumer_key="a1191fd420e0164c2f9aeac32ed35d23",

                               oauth_token="827fa00c6f15db4063378bb988e1563e0c318dbc",

                               oauth_signature_method="RSA-SHA1",

                               oauth_signature="f863cceebb4f1fe60739b125128e7355dcbf14ea",

                               oauth_timestamp="1258328889",

                               oauth_nonce="3c93e7fdd1101e515997abf84116ef579dccce1a",

oauth_version="1.0"

POST /albums/2009/08/1011/duplicate;t=a5d0e32ddff373df1b3351e53fc6ffb1 HTTP/1.1

> Korumalı bir kaynağa erişim isteği;

Authorization: OAuth oauth_consumer_key="a1191fd420e0164c2f9aeac32ed35d23",

oauth_token="827fa00c6f15db4063378bb988e1563e0c318dbc",

oauth_signature_method="RSA-SHA1",

oauth_signature="f863cceebb4f1fe60739b125128e7355dcbf14ea",

oauth_timestamp="1258328889",

oauth_nonce="3c93e7fdd1101e515997abf84116ef579dccce1a",

oauth_version="1.0"

 > Erişim token ve erişim secret key içeren bir Yetkilendirme başlığı içeren istek;

Akış karmaşık gibi görünse de istemcilerin kullanıcının verilerine erişmesine izin verecek şekilde tasarlanmıştır. Kullanıcı adı ve şifre bilgisini sormadan, kullanıcı sunucudan herhangi bir istemcinin iznini iptal etmesini isteyebilir.

İki Aşamalı OAuth

  İki aşamalı OAuth kimlik bilgilerini sunucuya şu yollarla sağlanan istemciye benzer. Yetkilendirme dahil olmadan temel veya özet kimlik doğrulamasını kullanan yetkilendirme başlığı ile.

OAuth spesifikasyonu bu kimlik doğrulama stilini belirtmediğini ancak sunucuya bir istemcinin kimlik doğrulamak için yaygın olarak kullanılır.

iki aşamalı OAuth aşağıdaki adımları içerir.

1-İstemci sunucudan bir anahtar ve  dışarıdan bir gizli anahtar ister. Anahtar müşteri için bir tanımlayıcıdır. Gizli anahtar ise; istemci ve sunucu arasında paylaşılan bir gizli anahtardır.

2-İstemci korunan bir kaynağa erişim talebinde bulunurken anahtar ve imzalama yönetimi ve işareti içeren yetkilendirme başlığına nature, timestamp, nonce isteğe bağlı olarak OAuth protokol sürümünü ekler.

Sunucu kaynağa erişim izni vermeden önce imzayı doğrular. Bu yaklaşım kimlik doğrulama akışında yalnızca iki taraf olduğu için iki ayaklı olarak adlandırılır. Sunucu istemcinin kimliğini doğrulaması gerektiğinde iki aşamalı OAuth kullanır. ( Erişim kontrolü, Günlük kaydı, ölçüm, hız sınırlama v.b )

İki aşamalı OAuth korumalı erişim sağlayan bir kaç istemcinin bulunduğu durumlar için uygundur. Sunucu her istemciye bir anahtar ve gizli anahtar verebilir. Müşteriyi bir imza com-OAuth göre  yerleştirilir. İki aşamalı OAuth aynı zamanda üç aşamalı OAuth destekler.

Örneğin; Bir müşterinin bir çalışanı işe alma sürecini uygulamak için sunucuyla etkileşime girer. İstemci son kullanıcılarının kimliğini doğrulamak için kendi kimlik doğrulama mekanizmasına sahiptir. Müşteri  kimlik doğrulamak için tanımlama bilgilerini web tabanlı bir uygulamaya girebilir. Sunucu istemcinin kimlik doğrulaması için iki aşamalı OAuth kullanması gerektiğinden her istekte bir sunucuya  Sunucunun atadığı varsayılan a1191fd420e0164c2f9aeac32ed35d23 oauth_consumer_key ve müşteri gizli anahtarı fd9b9d0f769c3bcc548496e4b5077da79c02d7be imza gönderir.  

Müşterinin yeni bir kaynak oluşturmak için aday bilgilerinin gönderdiğini varsayalım ve kimliği doğrulanmış bir istekte bulunmak için istemcinin bir yetkilendirme başlığı eklemesi gerekir.

oauth_signature parametresinin değeri sonuç olarak müşterinin daha sonra yetkilendirme başlığını takip eder ve istekte bulunur.

# Request to enter candidate info

POST /hires HTTP/1.1

Host: www.example.org

Authorization: OAuth realm="http://www.example.com/hires",

                               oauth_consumer_key=a1191fd420e0164c2f9aeac32ed35d23,

                               oauth_nonce=85a55859fde262ba,

                               oauth_signature=d8e19bb988110380a72f6dba33b2ba5903272fe1,

                               oauth_signature_method=HMAC-SHA1,

                               oauth_timestamp=1258308689,

                               oauth_version=1.0

Content-Type: application/json

{

   "name": "Joe Prospect",

   ...

}

# Response

HTTP/1.1 201 Created

Location: http://www.example.org/hires/099

Content-Location: http://www.example.org/hires/099

Content-Type: application/json

{

   "name": "Joe Prospect",

   "id": "urn:example:hr:hiring:099",

   ...

   "link" : {

      "rel" : "http://www.example.org/rels/hiring/post-ref-result",

      "href" : "http://www.example.org/hires/099/refs"

   }

}

POST /hires HTTP/1.1 > korumalı bir kaynağa erişim isteği;

Authorization: OAuth realm="http://www.example.com/hires",

oauth_consumer_key=a1191fd420e0164c2f9aeac32ed35d23,

oauth_nonce=85a55859fde262ba,

oauth_signature=d8e19bb988110380a72f6dba33b2ba5903272fe1,

oauth_signature_method=HMAC-SHA1,

oauth_timestamp=1258308689,

oauth_version=1.0

> Tüketici anahtarı ve tüketici gizli anahtarı (imza) kullanılarak hesaplanan yetkilendirme başlığı;

 

OAuth; istemcilerin kimlik bilgilerini sorgu parametreleri aracılığıyla sağlanmasına da izin verdiğini unutmayalım.  

# Request to enter candidate info

POST /hires?oauth_consumer_key=a1191fd420e0164c2f9aeac32ed35d23&

                  oauth_nonce=85a55859fde262ba&

                  oauth_signature=d8e19bb988110380a72f6dba33b2ba5903272fe1&

                  oauth_signature_method=HMAC-SHA1&

                  oauth_timestamp=1258308689&oauth_version=1.0 HTTP/1.1

Host: www.example.org

Content-Type: application/json

{

   "name": "Joe Prospect",

   ...

}

Ancak; Yetkilendirme üstbilgisinin kullanılması URI çoğalmasını azaltır.

İstemci geçerli bir Yetkilendirme üstbilgisini ekleyemezse; sunucu WWW-Authenticate başlığı ve 401 (Yetkisiz) yanıt başlığı cevabı döner.

# Request to enter candidate info

POST /hires HTTP/1.1

Host: www.example.org

Content-Type: application/json

{

   "name": "Joe Prospect",

   ...

}

# Response

401 Unauthorized

WWW-Authenticate: OAuth realm="http://www.example.com/hires"

Content-Type: text/html;charset=UTF-8

<html>

   ...

   <body>

      <p>Unauthorized.</p>

   </body>

</html>

Bu işlem sunucunun kimlik doğrulama için OAuth kullandığını gösterir.

İstemcilerin Kimlik Doğrulamasında Temel Kimlik Doğrulama Kullanımı

 

  İstemcide, müşteri tanımlayıcısının birleştirilmesi kullanıcı adı ve paylaşılan şifre <identifier>:<secret> ardından bu metinin Base64 kodlamasını dahil etmeniz gerekir. İstemci isteklerinde bir metin başlığı ortaya çıkaran metin değeri : Authorization: Basic <Base64 encoded value>

Sunucuda metnin kodunu çözün ve şifrenin aynı olduğunu doğrulayın. İstemci sunucunun bir kaynak için temel kimlik doğrulaması gerektiğini önceden biliyorsa her istek geldiğinde yetkilendirme üst bilgisi içerilebilir. 401 alınması önlenebilir.

iki kişi için temel ve özet kimlik doğrulama gibi kimlik doğrulama şemaları kullanılabilir.

Senaryolar: Bir müşteri korunan bir kaynağa kendi adına eriştiğinde ve bir müşteri bir kullanıcı adına korumalı bir kaynağa erişiyorsa.

İstemcide güvenli bir şekilde saklanmadıkça hiç bir sır gerçekte güvenli değildir.

Temel kimlik doğrulama; HTTP 1.0'a kadar uzanır ve daha sonra RFC 2617 tarafından belirtilir. Temel kimlik doğrulamasında istemci Base 64 paylaşılan şifre kodlar ve bunu Yetkilendirme isteği başlığı ile destekler.

Base64 kodlaması tersine çevrilebilir. Aşağıdaki durumlarda temel kimlik doğrulaması kullanmayın. Sunucuya bağlanmak için TLS kullanmaz.

Aşağıdaki kodda bir kaynağa erişmeye çalışan bir istemcinin ilk isteğine yer verilmiş.

# Request

GET /photos HTTP/1.1

Host: www.example.org

# Response

401 Unauthorized

WWW-Authenticate: Basic realm="Photos App"

Content-Type: application/xml;charset=UTF-8

<error xmlns:atom="http://www.w3.org/2005/Atom">

   <message>Unauthorized.</message>

</error>

# Request

GET /photos HTTP/1.1 > Kimlik bilgileri olmayan bir istek

# Response

401 Unauthorized

WWW-Authenticate: Basic realm="Photos App" > Temel kimlik doğrulaması kullanarak kimlik bilgilerini sağlamayı zorlayan yanıt.

Kaynak korunduğundan, sunucu istemcinin kimlik bilgilerini sağlamasını ister. Basic adlı bir kimlik doğrulama şeması kullanarak, gerçek değeri opak dizedir. Sunucuda korunan bir alanı tanımlar.

İstemcinin / kullanıcının paylaşılan gizli değeri ile photoapp.001 olarak tanımlandığını varsaydığımızda basicauth. istemci photoapp.001. dizesinin Base64 kodlamasını hesaplar.  Cauth ve Yetkilendirme başlığıyla aşağıdaki isteği gönderir.

# Request

GET /photos HTTP/1.1

Host: www.example.org

Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA==

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset-UTF8

Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA== > Sunucu kimlik bilgilerini Base64 kullanarak çözer yöneticinin, istemcinin kattığı sunucu tarafından bilinenle eşleşir ve istemciye izin verilir. Sunucu alınan istekte bir istek daha alırsa yada yetkilendirme başlığı yoksa veya sağlanan yetkilendirme başlığındaki bilgiler ile eşleşmiyorsa sunucu WWW-Authentication hatasını döndürür.

Kimliği doğrulanmış yanıtlar hassas bilgiler içerdiğinden Cache-Control ve Expires üst bilgileri yanıtı için uygundur.

Örneğin; Yanıt istemciye özeldir, paylaşmayı önlemek için Cache-Control :private kullanın. Yanıtı saklamaktan veya diğer istemcilere sunmakta için gelen önbelleklerde kullanılır.

# Request

GET /users/admin HTTP/1.1

Host: www.example.org

Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA==

# Response

HTTP/1.1 200 OK

Cache-Control: max-age:3600,private

Vary: Authorization

Content-Type: application/xml;charset-UTF8

Yetkilendirme Başlığını Genişletme

Özet Kimlik Doğrulaması ve OAuth kimlik bilgilerini sunucuya göndermek için bu başlık kullanılır. Örneği Amazonun Basit Deploma Hizmeti (s3)bu başlığı kullanarak istemciler aşağıdaki istek başlığı kullanarak sunucuya kimlik doğrulaması yapar.

Authorization: AWS AWSAccessKeyId:Signature

Burada AWS Amazon tarafından kullanılan kimlik doğrulama şeması için tanımlayıcıdır.  Amazon aynı verilerin imzasını hesaplayarak istemcinin kimliğini doğrular.

İstemcilerin Kimlik Doğrulamasında Özet Kimlik Doğrulama

 Temel kimlik doğrulamaya benzer istemcinin kimlik bilgilerinin özetini sunucuya göndermesi dışında yeniden kimlik gönderim saldırılarını önlemek için mekanizmaları sağlar.

İstemci erişim için bir Yetkilendirme başlığı eklemeden bir istek gönderdiğinde korumalı kaynak dönüş kodu olarak 401 ile birlikte özet kimlik doğrulama şemasında bilgiler alır. Bu bilgiler bir kez yada sınırlı sayıda alınabilen bilgilerdir.

Sağlanan özetin içerisinde depolanan kimlik bilgilerinin bir özetiyle eşleştiğini doğruladıktan sonra Authentication-Info başlığı ekleyin. Bu bilgi sunucu tarafında eşdeğerdir.

İstemciler genel olarak özeti hesaplamak için MD5 kullanır. Temel kimlik doğrulamasından farklı olarak bu teknik şifrelenmemiş bir paylaşılan sırrı değiş tokuş etmez.

# Request

GET /photos HTTP/1.1

Host: www.example.org

# Response

401 Unauthorized

WWW-Authenticate: Digest realm="Sample app", nonce="6cf093043215da528d7b5039ed4694d3",

         qop="auth"

Content-Type: application/xml;charset=UTF-8

<error xmlns:atom="http://www.w3.org/2005/Atom">

   <message>Unauthorized.</message>

</error>

# Request

GET /photos HTTP/1.1

Host: www.example.org

Authorization: Digest username="photoapp.001", realm="Sample app",

nonce="6cf093043215da528d7b5039ed4694d3",

         uri="/photos", response="89fba5bf5e5f9dd69865258c21860956",

         cnonce="c019e396409afe784ae9f203b8dfdf7e", nc=00000001, qop="auth"

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset-UTF8

GET /photos HTTP/1.1   > kimlik bilgisi olmayan bir istek;

# Response

401 Unauthorized

WWW-Authenticate: Digest realm="Sample app", nonce="6cf093043215da528d7b5039ed4694d3",

qop="auth" > nonce içeren yanıt

cnonce="c019e396409afe784ae9f203b8dfdf7e", nc=00000001, qop="auth"  > Yanıt yönergesi içeren istek.

Temel kimlik doğrulamasından farklı olarak özet kimlik doğrulaması, istemcinin bir özet sağlaması gerekir.

realm : Sunucudaki korumalı alanı tanımlayan opak bir dize.

nonce: Her 401 Yetkisiz yanıtıyla benzersiz şekilde oluşturulan dize. Bir özet oluştururken bu değeri kullanmaları gerekir. Yeniden isteklerde kullanılan bazı değerlerden daha eski nonce yönergeleri kullanarak yapılan saldırıları içerir.

qop: Özet kimlik doğrulaması yönergeler için iki değer belirtir. Aut ve Auth-int. 

Auth:  Sunucunun istemci kimlik doğrulaması için özet kimlik doğrulaması kullandığını belirtir.

Auth-int: Sunucunun bu kimlik doğrulamasını aynı zamanda isteklerin bütünlüğü Qop = auth-int istemcilerin isteğinin gövdesine özeti hesaplarken ekler. 

*İstemci / Kullanıcı tanımlayıcısının, alanı ve paylaşılan gizli değer aşağıdaki şekilde birleştirin.  MD5 değerini hesaplayın. Değeri : A1 dir.

<identifier>:<realm>:<secret>

*İstek Yönetimini ve istek URL sini <method>:<URI> MD5 ekleyin. Sonucunun A2 olduğunu söyleyin.

*A1, nonce ve A2 yi <A1>:<nonce>:<A2> olarak birleştirin ve MD5 değerini hesaplayın.

Kullanıcı elde edilen değeri yanıt değeri olarak kullanır.

Nonce kullanımında; Sunucular tek seferlik veya sınırlı kullanımlı bir belirteç kullanarak saldırıların yeniden tekrarlanma olasılığını sınırlayabilir.

Tek seferlik veya sınırlı kullanılan biletler, requestlerde sunucunun kullanılan tüm belirteçlerinin günlüğünün tutulması gerekir.

WWW-Autheticate başlığı ayrıca domanin, opaque gibi diğer direktifleri içerebilir.

Blok ve Bloklanan İşler

 İdeal olarak veritabanı uygulamanızın veritabanı kullanıcı sayısı ile doğrusal olarak ölçeklenmesi gerekir. Ancak kullanıcı sayısı arttıkça kullanıcı sayısı performansı düşürdüğü yaygın bir durumdur. Artan ölçekle ilişkili olan bozulmanın nedeni engellemedir.

SQL Serverda engellemenin temelleri;

*ACID özellikleri

*Veritabanı kilit ayrıntı düzeyi, yükseltme, modlar ve uyumluluk.

*ANSI izolasyon seviyeleri

*Dizinlerin kilitlenme üzerindeki etkisi

*Engellemeyi analiz etmek için gerekli bilgiler

*Engellemeyi önlemek için kararlar ve öneriler

*Engelleme algılama ve bilgi toplama süreçlerinin otomatikleştirme teknikleri,

Atomiklik, Tutarlılık, İzolasyon, Dayanıklılık.

USE AdventureWorks2012;

GO

IF (SELECT OBJECT_ID('dbo.ProductTest')

    ) IS NOT NULL

      DROP TABLE dbo.ProductTest;

GO

CREATE TABLE dbo.ProductTest (

ProductID INT CONSTRAINT ValueEqualsOne CHECK (ProductID = 1));

GO

--All ProductIDs are added into t1 as a logical unit of work

INSERT INTO dbo.ProductTest

          SELECT p.ProductID

          FROM Production.Product AS p;

GO

SELECT *

FROM dbo.ProductTest; --Returns 0 rows

 

SQL Server önceki INSERT deyimini mantıksal çalışma birimi olarak ele alır. Sütundaki CHECK kısıtı ProductTest tablosunun ProductID sinini yanlızca 1 değerine izin verir. Bu nedenle ProductTest tablosuna hiç bir kayıt eklemeyecektir. CHECK nedeniyle hata oluşacaktır. Bu SQL Server tarafından otomatik olarak sağlanır.

BEGIN TRAN

 --Start: Logical unit of work

--First:

INSERT INTO dbo.ProductTest

            SELECT p.ProductID

            FROM Production.Product AS p;

--Second:

INSERT INTO dbo.ProductTest

VALUES (1);

COMMIT --End: Logical unit of work

GO

SQL Serverda önceki ekleme görevinden birden çok INSERT çalıştığını düşünerek daha büyük bir işin çalıştığını düşünürsek;  yukarıdaki gibi daha büyük mantıksal çalışma birimi oluşacaktır. Önceki komut dosyası zaten oluşmuş olan ProductTest tablosu ile BEGIN TRAN ve COMMIT çifti ile tüm ifadelerin atomik olması gerektiğini öneren mantıksal çalışma birimini tanımlar. ilk INSERT ifadesi başarısız olacak oysa ikinci INSERT makuldur ve varsayılan davranış ikinci INSERT ifadesinden SQL Server yürütmesine izin verecektir.

Kullanıcı tanımlı işlemin atomikliği 2 yolla sağlanır.

* SET XACT_ABORT ON

* Explicit rollback

SET XACT_ABORT ON

SET XACT_ABORT ON deyimini kullanarak işlemin atomikliği değiştirilebilir.

SQL Server komuttaki bir işlemin başarısız olduğunda otomatik olarak geri dönüş yapıp yapmayacağının karar vermesini sağlar. INSERT ifadesindeki birinci aşamadaki işlem başarısız olursa otomatik olarak ikinci INSERT ifadesini yürütmeyecektir. SET XACT_ABORT bağlantı düzeyinde yenide yapılandırılıncaya kadar yada bağlantı kurulana kadar geçerli kalır. Varsayılan olarak bu özellik kapalıdır.

SET XACT_ABORT ON;

GO

BEGIN TRAN

 --Start: Logical unit of work

--First:

INSERT INTO dbo.ProductTest

            SELECT p.ProductID

            FROM Production.Product AS p;

--Second:

INSERT INTO dbo.ProductTest

VALUES (1);

COMMIT

 --End: Logical unit of work GO

SET XACT_ABORT OFF;

GO

Explicit rollback

TRY/CATCH hata yakalama mekanizmasını kullanarak kullanıcı tanımlı bir işlemin atomikliğini yönetebilirsiniz. SQL Server içerisinde TRY kod bloğu içinde ifade hata alırsa kodu CATCH bloğuna hatayı paslayarak tüm işlemler geri alınabilir ve sonraki ifadelerin yürütülmesi engellenebilir.

BEGIN TRY

      BEGIN TRAN

      --Start: Logical unit of work

      --First:

      INSERT INTO dbo.ProductTest

                  SELECT p.ProductID

                  FROM Production.Product AS p

 

      Second:

      INSERT INTO dbo.ProductTest

                  (ProductID)

      VALUES (1)

      COMMIT --End: Logical unit of work

END TRY

BEGIN CATCH

      ROLLBACK

      PRINT 'An error occurred'

      RETURN

END CATCH

Kilit İçeriğini En Aza İndirgeme

 

  Kaynaklardan birinde kilit isteğinden kaçınarak kilitlenme çözülebilir. Kaynağa yanlızca veri okumak için erişilir. Bir kaynak üzerinde değişiklik yapmak her zaman özel bir kilit kazanacaktır. Kaynağın tutarlılığını korumak için kilitlenme durumunda kaynak erişimlerini tanımlanması gerekir. Salt okunur, kirli okuma özelliklerini kullanarak karşılıklı gelen kilit isteklerinden kaçınmaya çalışın.

Kaynak kilitlerinden kaçınmak için aşağıdaki tetikler kullanılır.

* Satır versiyonlama Uygulamak

* İzolasyon seviyesini arttırmak

* Kilitlenme ipuçlarının kullanılması.

Satır versiyonlama Uygulamak

Katı kilitlenme şeması kullanarak kaynaklara erişim engelleye çalışmak yerine READ_COMMITTED_SNAPSHOT izlosayon seviyesi veya SNAPSHOT izolasyon seviyesi ile satır versiyonlama. Satır versiyonlama izolasyon seviyelerini engellemeyi azaltmak için kullanılıyor. 

ALTER DATABASE AdventureWorks2012

SET READ_COMMITTED_SNAPSHOT ON;

Yukarıdaki T-SQL ile tempdb de bulunan satırların bir sürümüne sahip olabilirsiniz potansiyel olarak önceki kilitlenme senaryosundaki kilitlenmenin neden olduğu detayı görebilirsiniz. Bu okumalar farklı bir sürümde olduğu için kilit çekişmesine neden olmadan gerekli tüm okumalara izin verecektir. Satır sürümleme ek yük getirecektir. Özellikle tempdb de sorguda kullanılan tablo, dizinler. Artan değiş tokuş azaltılmış kilitlenmeler ve artan eşzamanlılık avantajına karşı ek yük ve maliyet değerlendirilebilir.

İzolasyon seviyesini arttırmak

Bazen bir SELECT ifadesi  tarafından istenen (S) kilidi dairesel engellemenin oluşumuna katkıda bulunacaktır.  SELECT deyimi içeren işlemin yalıtım düzeyini azaltarak bu tür döngüsel engellemelerden kaçınılabilir. SELECT ifadesindeki (s) kilidi istenmeden verilerin okunmasına ve böylece dairesel engellemelerden kaçınmasına yarar sağlayacaktır.  Ancak öngörülmeyen verilerin okunması kötü verileri döndürerek ciddi sorunlara sebep verecektir. 

Ayrıca bağlantıların kendilerini SERİLEŞTİRİLEBİLiR olarak ayarlayıp ayarlamadığını kontrol etmeniz gerekir. Bazen çevrimiçi bağlantı dizisi oluşturucuları bu seçeneği içerecek ve geliştiricilerinde bunu kullanması sonucunda istenmeyen sonuçlara yol açabilecektir. MSDTC varsayılan olarak serileştirilebilir kullanılır ancak bu değiştirilebilir.

Kilitlenme ipuçlarının kullanılması.

READ UNCOMMITTED izolasyon seviyesi gibi NOLOCK veya READUNCOMMITTED kilitlenme ipucu (s) kilitlerini önleyecektir. Belirli bir oturum tarafından istenir, böylece dairesel blokaj oluşumunu engeller.

Kilitleme ipucu etkisi sorgu düzeyindedir. Uygulandığı tablo ve dizinlerle sınırlıdır. NOLOCK ve  READUNCOMMITTED kilitlenme ipuçları yanlızca SELECT deyimlerinden ve veri seçim bölümlerinde izin verilir.

INSERT, DELETE, UPDATE

Kirli okuma sayfa bölümleri nedeniyle eksik veya fazla satırları içerebilir. Bu teknik sadece düşük kaliteli verilerin olduğu durumlarda kullanılabilir.

DeadLock işlemlerinden Kaçınma

Kilitlenmeyi önleyebileceğimiz teknikler;

1- Kaynaklara aynı fiziksel sırayla erişim,

2-Erişilen kaynakların sayısının azaltılması,

3-Kilit çelişkisinin azaltılması.

1- Kaynaklara Aynı Fiziksel Sıra ile Erişim 

Aynı fiziksel düzendeki kaynaklara her işlemin eriştiğinden emin olunması gerekiyor. Her işlem kaynaklara aynı fiziksel sırada erişirse ilk işlem başarılı gerçekleşecek ikinci işlem tarafından engellenmeden işini bitirecektir. ikinci işlem işine devam edebilecektir.  İlk işlem işini bitirmeden ikinci işlem kaynağa erişime çalışırsa bu sefer birinci işlem işlemi bloke edecektir. Buda dairesel bir engellemeye yol açacaktır. 

İşlemlerden;

Transaction-1 [Access Resource 1] + [Access Resource 2]

Transaction-2 [Access Resource 2] + [Access Resource 1]

Resource 1, hobtid=72057594046578688: This is the index row within index

      PK_ PurchaseOrderDetail_PurchaseOrderId_PurchaseOrderDetailId on the

      Purchasing.PurchaseOrderDetail table.

Resource 2, hobtid=72057594046644224: This is the row within clustered index

PK_PurchaseOrderHeader_PurchaseOrderId on the Purchasing.PurchaseOrderHeader table.

Yukarıdaki mesaj kilitlenme senaryosuna örnek mesajı teşkil etmektedir. 

2- Erişilen Kaynak Sayısının Azaltılması

Bir kilitlenme en az iki kaynak içerir. Bir otorum bir kaynağı tutar ve ardından ikinci kaynağı ister. Diğer oturum ikinci kaynağı tutar ve ilk kaynağı ister. Çıkmaza dahil olan kaynaklardan birine erişirseniz kilitlenmeyi önleyebilirsiniz. Dirençli bir çözüm olarak uygulama yeniden tasarlanarak bu önlenebilir. Ancak, Uygulama tasarımı değiştirilmeden SQL Server aşağıdaki özellikleri kullanmayın düşünebilirsiniz.

* Kümelenmemiş bir dizinin kümelenmiş bir dizine dönüştürülmesi.

* SELECT ifadesi için bir kaplama index kullanılması.

* Kümelenmemiş bir dizinin kümelenmiş bir dizine dönüştürülmesi.

Kümelenmiş ve kümelenmemiş dizinin sayfaları birbirlerinden farklıdır. Kümelenmemiş dizin iki kilit alır, biri taban (küme veya yığın) diğeri kümelenememiş dizin. Kümelenmemiş dizinde yaprasak sayfaları ve dizinin veri sayfaları tabloda aynıdır. Tek kilit gerektirir, bu kilit hem kümelenmiş dizini hemde tabloyu korur. Sebebi yaprak sayfaları ve veri sayfaları aynıdır. Bu aynı sorgu ile erişilecek kaynakların sayısı azaltılır. (Ancak kümelenmemiş bir dizine karşı bu geçerlidir.) Bu işin çalışması için tamamen bunun uygun kümelenmiş index olmasına bağlıdır.

* SELECT ifadesi için bir kaplama index kullanılması.

SELECT ifadesi kaplama dizinin kendisinden her şeyi alabilir. Teme tabloya erişmesine gerek yoktur. SELECT deyiminin temel tabloya erişimini durdurarak temel  tabloyu başka bir oturum tarafından kilitlenir.

DeadLock Analiz #2

Öncelikle kilitlenme bayrağı 1222 ve xml_deadlock_report olaylarının kullanıma açıldığından emin olmamız gerekiyor.

Tek bir bağlantıda aşağıdaki komut çalıştırılabilir;

BEGIN TRAN

UPDATE Purchasing.PurchaseOrderHeader

SET Freight = Freight * 0.9 -- 10% discount on shipping

WHERE PurchaseOrderID = 1255;

ikinci bağlantıda aşağıdaki komut çalıştırılabilir.

BEGIN TRANSACTION

UPDATE Purchasing.PurchaseOrderDetail

SET OrderQty = 4

WHERE ProductID = 448

AND PurchaseOrderID = 1255;

Yukarıdaki komutlar çalıştırıldığında her biri bir işlem açar ve verileri işlemeye başlar. Ancak ne kadar zamanda işlemi yapacağını ve geri alacağını bilemiyoruz.

Birinci komuta gidip aşağıdaki işlemi çalıştırılalım;

UPDATE Purchasing.PurchaseOrderDetail

SET OrderQty = 2

WHERE ProductID = 448

AND PurchaseOrderID = 1255;

İlk bağlantı büyük ihtimalle bir kaç saniye sonra bir kilitlenme oluşacaktır. 

Msg 1205, Level 13, State 51, Line 1

Transaction (Process ID 52) was deadlocked on lock resources with another process and has been

chosen as the deadlock victim. Rerun the transaction.

Önce izleme olayı aracılıyla toplanan kilitlenme grafiğini incelememiz ardından xml_deadlock_report olay için bu pencerede verilen grafiği incelememiz gerekir. 

Ancak daha detaya inerek kilitlenme olayının tam olarak nerede olduğu hangi süreçlerin buna neden olduğu hangi nesnelerin dahil edildi bilgileri XML dosyasını doğrudan genişletilmiş olay grafiğini değerlerinden bulabiliriz.

Örnek tabloda uPurchaseOrderDetail adlı bir tetikleyici bulunuyor. Tüm bu bilgiler hangi kod parçalarının kilitlenmeye yol açtığını belirlememizde yardımcı olacaktır. Ayrıca SQL Handle  gibi bilgileri almak, DMO lar ile birlikte ifadeleri almak kilitlenme ile ilgili bilgilerde bize yardımcı olacaktır.

İzleme bayrağı 1222 tarafından toplanan veriler ile XML içerisindeki bilgiler hemen hemen aynıdır.  Ana farklılıkları biçimlendirme ve konumudur. İzleme bayrağı 1204 tarafından toplanan veriler ise tamamen farklıdır.  Kullanabiliyorsanız Genişletilmiş olayları kullanmaya devam etmeniz işinizin kolaylaşması açısında daha iyidir. 1222 takip edilmesi genellikle önerilir. system_health içinde oluşan bilgilerde size yardımcı olacaktır. 

Yukarıdaki örnekde kilitlenme Purchasing.PurchaseOrderDetail  tablosundaki bir tetikleyiciden kaynaklanmaktadır. Miktar güncellendiğinde Purchasing.PurchaseOrderDetail tablosunda Purchasing.PurchaseOrderHeader tablosu güncellemeye çalışır. İlk iki sorgu çalıştığında her biri açık bir işlem üzerinde bir engelleme durumu söz konusu olur. İkinci sorgu ilk sorgunun temizlenmesini bekler böylece Purchasing.PurchaseOrderHeader tablosunu güncelleyebilir. Sorunu çözebilmek için süreçlerden birini öldürmektir.

Deadlock Analiz #1

 

Oluşan sorunların nedenlerini analiz ederken sonradan oluşabilecek sorunları önleyebiliriz.

* Deadlock oturumları

* Deadlock oluşturan kaynaklar

* Sessionlar tarafından yürütülen sorgular.

Kilitlenme Bilgilerinin Toplanması 

Bu bilgileri toplamanın 4 yolu vardır.

1-1222 flag izlemesinin ayarlanması

2-1204 flag izlemesinin ayarlanması

3-İzleme olaylarının kullanılması

4-Genişletilmiş olayların kullanılması

İzleme bayrakları kilitlenme durumlarının oluşmasında belirli SQL Server davranışlarının özelleştirmesi için kullanılır. Ancak bu bilgi edinme eski bir yöntem olmuştur. SQL Server 2008 den beri kullanılan örnekte; system_health adın bir genişletilmiş olay oturumu vardır. Oturum otomatik olarak çalışır ve olaylarından birini varsayılan olarak toplar. Bu kilitlenme bilgilerine anında erişmek için en kolay yoldur.

System_health sadece anlık olayları için kullanılabiliyor. Verileri yakalamak için ring_buffer kullanıldığı için bir kilitlenme yaşandıktan hemen sonra bu parametreye bakıyorsanız bilgilerin eksik olduğunu görebileceksiniz. Daha uzun süreli bilgi toplamak gerekli olursa mümkün olduğunda çok olay toplamamız gerekiyor.  Genişletilmiş olaylar kilitlenme bilgilerini toplamak için birkaç yol sağlamaktadır. Bu en iyi yollardan biridir. 

1- Lock_deadlock: Bir kilitlenme olayı hakkkında temel bilgileri görüntülenmesini sağlar.

2-Lock_deadlock_chain: bir kilitlenmedeki her oturumda bilgi alır.

3-Xml_deadlock_report : Kilitlenme nedeniyle beraber XML şeklinde grafik sağlar.

Temel kilitlenme bilgileri için en kolay yol xml_deadlock_report görünüyor. Aynı zamanda Lock_deadlock_chain kullanmak yardımcı olacaktır.

Kilitlenme grafiğini Management Studioda açabiliriz. XMLde de arama yapabiliriz.  XML kilitlenme için neredeyse bir yürütme planı gibi çalışır.

Kilitlenme bilgisini oluşturan iki izleme bayrağı farklı veriler oluşturmak için tek tek veya birlikte kullanılabilir.

Genellikle biri kullanılır bunu sebebi ise çok fazla veri olmasındandır.  SQL Server hata günlüğünü, izleme bayraklarını, toplanan verileri, kilitlenme olaylarını bir günlük dosyasına yazar. İzleme bayrağı 1222 kilitlenme olayları ile ilgili olarak ayrıntılı bilgiler çıkarır. Bilgileri kaynağa göre sıralar ve süreçler hakkında daha fazla bilgi sağlar.

İzleme bayrağı1204 ise; kilitlenme nedenini analiz etmemize yardımcı olarak ayrıntılı kilitlenme bilgileri sağlar. Kilitlenmeye dahil olan tüm düğümleri ayrıntılı olarak çıkarır.

DBCC TRACEON izleme bayraklarını açmak ve etkileştirmek için kullanılır. Açılan izleme bayrakları DBCC TRACEOFF  deyimi kullanılana kadar devrede kalır. Eğer sunucu yeniden başlatılırsa bu izleme bayrakları silinecektir. 

DBCC TRACESTATUS deyimini kullanarak izleme bayraklarının durumunu belirleyebiliriz.

DBCC TRACEON (1222, -1);

DBCC TRACEON (1204, -1);

SQL Server Management Studio üzerinden izleme bayraklarının ayarlanması başlangıçta yapılabilir.