MQTT aracısı kimlik doğrulamasını yapılandırma

Makale
12/09/2024

Önemli

Bu sayfa, önizleme aşamasında olan Kubernetes dağıtım bildirimlerini kullanarak Azure IoT İşlemleri bileşenlerini yönetme yönergelerini içerir. Bu özellik çeşitli sınırlamalarla sağlanır ve üretim iş yükleri için kullanılmamalıdır.

Beta veya önizleme aşamasında olan ya da başka bir şekilde henüz genel kullanıma sunulmamış olan Azure özelliklerinde geçerli olan yasal koşullar için bkz. Microsoft Azure Önizlemeleri için Ek Kullanım Koşulları.

MQTT aracısı istemciler için birden çok kimlik doğrulama yöntemini destekler ve her dinleyici bağlantı noktasını bir BrokerAuthentication kaynağıyla kendi kimlik doğrulama ayarlarına sahip olacak şekilde yapılandırabilirsiniz. Kullanılabilir ayarların listesi için bkz. Aracı Kimlik Doğrulaması API'sinin başvurusu.

BrokerListener ve BrokerAuthentication'ı bağlama

Aşağıdaki kurallar BrokerListener ile BrokerAuthentication kaynakları arasındaki ilişki için geçerlidir:

Her BrokerListener'ın birden çok bağlantı noktası olabilir. Her bağlantı noktası bir BrokerAuthentication kaynağına bağlanabilir.
Her BrokerAuthentication aynı anda birden çok kimlik doğrulama yöntemini destekleyebilir.
BrokerAuthentication kaynağına bağlanmamış bağlantı noktalarının kimlik doğrulaması devre dışıdır.

BrokerListener bağlantı noktasını Bir BrokerAuthentication kaynağına bağlamak için, AracıListener kaynağının ayarında ports alanını belirtinauthenticationRef. Daha fazla bilgi için bkz . BrokerListener kaynağı.

Varsayılan BrokerAuthentication kaynağı

Azure IoT İşlemleri, ad alanında azure-iot-operations varsayılan dinleyiciyle bağlantılı adlı default bir varsayılan BrokerAuthentication kaynağı dağıtır. Kimlik doğrulaması için yalnızca Kubernetes Hizmet Hesabı Belirteçlerini (STS) kullanır.

Önemli

Azure IoT İşlemlerindeki bileşenlerin düzgün çalışması için varsayılan BrokerAuthentication kaynağındaki hizmet hesabı belirteci (SAT) kimlik doğrulama yöntemi gereklidir. Varsayılan BrokerAuthentication kaynağını güncelleştirmekten veya silmekten kaçının.

Azure portalında IoT İşlemleri örneğinize gidin.
Bileşenler'in altında MQTT Aracısı'ni seçin.
Kimlik Doğrulaması sekmesini seçin.
Kimlik doğrulama ilkesi listesinden varsayılan ilke adını seçin.

Yeni kimlik doğrulama yöntemleri eklemek için Yöntem ekle'yi seçin.

Varsayılan uç noktayı düzenlemek için aşağıdaki içeriğe sahip bir Bicep .bicep dosyası oluşturun. Ayarları gerektiği gibi güncelleştirin ve gibi <AIO_INSTANCE_NAME> yer tutucu değerlerini kendi yer tutucunuzla değiştirin.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource defaultBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: 'default'
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
          ]
        }
      }
    ]
  }
}

Azure CLI kullanarak Bicep dosyasını dağıtın.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Varsayılan aracı kimlik doğrulama kaynağını incelemek için şunu çalıştırın:

kubectl get brokerauthentication default -n azure-iot-operations -o yaml

Çıktıda varsayılan BrokerAuthentication kaynağı gösterilir ve meta veriler kısa süre için kaldırılır:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
          - aio-internal

Değişiklik yapmanız gerekiyorsa, hedef kitleyle aio-internal SAT kimlik doğrulama yöntemini korurken bu kaynaktaki alanı değiştirinauthenticationMethods. Ardından kullanarak kubectl applydağıtın.

Kimlik doğrulama akışı

Belirtilen kimlik doğrulama yöntemlerinin sırası, MQTT aracısının istemcilerin kimliğini nasıl doğruladığını belirler. MQTT aracısı, belirtilen ilk yöntemi kullanarak istemcinin kimlik bilgilerini doğrulamaya çalışır ve bir eşleşme bulana veya sona ulaşana kadar belirtilen yöntemler arasında yinelenir.

Her yöntem için MQTT aracısı önce istemcinin kimlik bilgilerinin bu yöntemle ilgili olup olmadığını denetler. Örneğin, SAT kimlik doğrulaması ile başlayan K8S-SATbir kullanıcı adı gerektirir ve X.509 kimlik doğrulaması için bir istemci sertifikası gerekir. İstemcinin kimlik bilgileri ilgiliyse, MQTT aracısı geçerli olup olmadığını doğrular. Daha fazla bilgi için Kimlik doğrulama yöntemini yapılandırma bölümüne bakın.

Özel kimlik doğrulaması için, MQTT aracısı özel kimlik doğrulama sunucusuyla iletişim kuramamasına ilgili olmayan kimlik bilgileri olarak davranır. Bu davranış, özel kimlik doğrulama sunucusuna ulaşılamıyorsa MQTT aracısının diğer yöntemlere geri dönmesini sağlar.

Kimlik doğrulama akışı şu durumlarda sona erer:

Bu koşullardan biri doğrudur:
- İstemcinin kimlik bilgileri yöntemlerden biri için geçerlidir.
- İstemcinin kimlik bilgileri hiçbir yöntemle ilgili değildir.
- İstemcinin kimlik bilgileri ilgili ancak yöntemlerden herhangi biri için geçersiz.
MQTT aracısı, kimlik doğrulama akışının sonucuna göre istemciye erişim verir veya erişimi reddeder.

Örneğin:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata: 
  name: default
  namespace: azure-iot-operations
spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # ...
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        # ...

Önceki örnekte özel ve SAT belirtildi. bir istemci bağlandığında, MQTT aracısı belirtilen yöntemleri kullanarak istemcinin kimliğini doğrulamayı dener özel sırayla, ardından SAT.

MQTT aracısı, istemcinin kimlik bilgilerinin özel kimlik doğrulaması için geçerli olup olmadığını denetler. Özel kimlik doğrulaması, kimlik bilgilerinin geçerliliğini belirlemek için bir dış sunucuya dayandığından aracı, özel kimlik doğrulamasıyla ilgili tüm kimlik bilgilerini dikkate alır ve bunları özel kimlik doğrulama sunucusuna iletir.
Özel kimlik doğrulama sunucusu ile Pass yanıt verirse veya Fail sonuç verirse, kimlik doğrulama akışı sona erer. Bununla birlikte, özel kimlik doğrulama sunucusu kullanılamıyorsa, MQTT aracısı kalan belirtilen yöntemlere geri döner ve SONRAKI SAT olur.
MQTT aracısı kimlik bilgilerini SAT kimlik bilgileri olarak doğrulamaya çalışır.

Özel kimlik doğrulama sunucusu kullanılamıyorsa ve sonraki tüm yöntemler sağlanan kimlik bilgilerinin uygun olmadığını belirlerse, aracı istemci bağlantısını reddeder.

Kimlik doğrulama yöntemini yapılandırma

Kimlik doğrulama ilkelerine X.509, SAT veya özel gibi kimlik doğrulama yöntemleri ekleyebilirsiniz.

İlkeye kimlik doğrulama yöntemi eklemek için:

Azure portalında IoT İşlemleri örneğinize gidin.
Bileşenler'in altında MQTT Aracısı'ni seçin.
Kimlik Doğrulaması sekmesini seçin.
Mevcut bir kimlik doğrulama ilkesini seçin veya yeni bir ilke oluşturun.
Yöntem ekle'yi seçerek yeni bir yöntem ekleyin.
Açılan listeden yöntem türünü seçin ve ardından Yöntemi yapılandırmak için Ayrıntılar ekle'yi seçin.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        customSettings: {
          endpoint: 'https://auth-server-template'
          caCertConfigMap: 'custom-auth-ca'
          auth: {
            x509: {
              secretRef: 'custom-auth-client-cert'
            }
          }
          headers: {
            header_key: 'header_value'
          }
        }
      }
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: 'client-ca'
          authorizationAttributes: {
            root: {
              attributes: {
                organization: 'contoso'
              }
              subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
            }
            intermediate: {
              attributes: {
                city: 'seattle'
                foo: 'bar'
              }
              subject: 'CN = Contoso Intermediate CA'
            }
            smartfan: {
              attributes: {
                building: '17'
              }
              subject: 'CN = smart-fan'
            }
          }
        }
      }
    ]
  }
}

Azure CLI kullanarak Bicep dosyasını dağıtın.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Bölümüne yeni yöntemler authenticationMethods ekleyerek bir kimlik doğrulama ilkesi için BrokerAuthentication kaynağını değiştirin. Aşağıdaki örnekte, BrokerAuthentication kaynağı için birden çok kimlik doğrulama yöntemi gösterilmektedir:

apiVersion: mqttbroker.iotoperations.azure.com/v1
kind: BrokerAuthentication
metadata:
  name: my-policy
  namespace: azure-iot-operations
spec:
  authenticationMethods:
  - method: Custom
    customSettings:
      endpoint: https://auth-server-template
      caCertConfigMap: custom-auth-ca
      auth:
        x509:
          secretRef: custom-auth-client-cert
      headers:
        header_key: header_value
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience
    - method: X509
      x509Settings:
        trustedClientCaCert: client-ca
        authorizationAttributes:
          root:
            attributes:
              organization: contoso
            subject: CN = Contoso Root CA Cert, OU = Engineering, C = US
          intermediate:
            attributes:
              city: seattle
              foo: bar
            subject: CN = Contoso Intermediate CA
          smart-fan:
            attributes:
              building: "17"
            subject: CN = smart-fan

Yapılandırmayı değiştirmek için, bu BrokerAuthentication kaynağındaki ayarı değiştirin authenticationMethods ve kullanarak kubectl applydağıtın.

Kimlik doğrulama seçeneklerinin her biri hakkında daha fazla bilgi edinmek için her yöntemin sonraki bölümlerine bakın.

Azure Key Vault yapılandırarak ve iş yükü kimliklerini etkinleştirerek güvenli ayarları etkinleştirme hakkında daha fazla bilgi için bkz . Azure IoT İşlemleri dağıtımında güvenli ayarları etkinleştirme.

X.509

İpucu

X.509 kimlik doğrulamasını yapılandırma hakkında uçtan uca bir örnek için bkz . Öğretici: TLS, X.509 istemci kimlik doğrulaması ve öznitelik tabanlı erişim denetimi (ABAC) yetkilendirmesi.

X.509 kimlik doğrulaması ile MQTT aracısı, istemci sertifikalarını doğrulamak için güvenilir bir CA sertifikası kullanır. Bu güvenilen CA bir kök veya ara CA olabilir. Aracı, istemci sertifika zincirini güvenilen CA sertifikasına karşı denetler. Zincir geçerliyse istemcinin kimliği doğrulanır.

X.509 kimlik doğrulamasını güvenilen bir CA sertifikasıyla kullanmak için aşağıdaki gereksinimlerin karşılanması gerekir:

TLS: X.509 TLS istemci sertifikalarını kullandığından, X.509 kimlik doğrulaması kullanan bağlantı noktaları için TLS'nin etkinleştirilmesi gerekir.
Anahtar algoritmaları: Hem EC hem de RSA anahtarları desteklenir, ancak zincirdeki tüm sertifikaların aynı anahtar algoritmasını kullanması gerekir.
Biçim: CA sertifikası PEM biçiminde olmalıdır.

İpucu

PEM biçimi, sertifikalar ve anahtarlar için ortak bir biçimdir. PEM dosyaları, ve -----BEGIN EC PRIVATE KEY-----gibi -----BEGIN CERTIFICATE----- üst bilgiler içeren base64 kodlu ASCII dosyalarıdır.

Başka bir biçimde bir sertifikanız varsa, OpenSSL kullanarak sertifikayı PEM'ye dönüştürebilirsiniz. Daha fazla bilgi için bkz . Sertifikayı uygun biçime dönüştürme.

Güvenilen CA sertifikası alma

Bir üretim kurulumunda, CA sertifikası bir kuruluşun ortak anahtar altyapısı (PKI) veya ortak sertifika yetkilisi tarafından sağlanır.

Test için OpenSSL ile otomatik olarak imzalanan bir CA sertifikası oluşturun. Örneğin, RSA anahtarı, ayırt edici bir ad CN=Contoso Root CA Certve 365 günlük geçerlilik ile otomatik olarak imzalanan bir CA sertifikası oluşturmak için aşağıdaki komutu çalıştırın:

openssl req -x509 -newkey rsa:4096 -keyout ca-key.pem -out ca.pem -days 365 -nodes -subj "/CN=Contoso Root CA Cert"

Sertifikaları yönetmek için kullanışlı bir araç olan Step CLI ile aynı komut şu şekildedir:

step certificate create "Contoso Root CA Cert" ca.pem ca-key.pem --profile root-ca --kty RSA --size 4096 --no-password --insecure
 --not-after 8760h

Bu komutlar, PEM biçiminde bir CA sertifikası ca.pem ve özel anahtar ca-key.pem oluşturur. CA sertifikası ca.pem , X.509 kimlik doğrulaması için MQTT aracısına aktarılabilir.

Güvenilen CA sertifikalarını içeri aktarma

X.509 kimlik doğrulamasını kullanmaya başlamak için, güvenilen CA sertifikasını ad alanında bir ConfigMap'e aktarın azure-iot-operations . Güvenilen CA sertifikasını ca.pem adlı client-cabir ConfigMap'e aktarmak için şunu çalıştırın:

kubectl create configmap client-ca --from-file=ca.pem -n azure-iot-operations

Bu örnekte, CA sertifikası anahtarı ca.pemaltında içeri aktarılır. MQTT aracısı ConfigMap'teki tüm CA sertifikalarına güvenir, bu nedenle anahtarın adı herhangi bir şey olabilir.

Kök CA sertifikasının düzgün içeri aktarıldığından emin olmak için komutunu çalıştırın kubectl describe configmap. Sonuç, PEM sertifika dosyasının aynı base64 kodlamasını gösterir.

kubectl describe configmap client-ca -n azure-iot-operations

Name:         client-ca
Namespace:    azure-iot-operations

Data
====
ca.pem:
----
-----BEGIN CERTIFICATE-----
MIIFDjCCAvagAwIBAgIRAKQWo1+S13GTwqZSUYLPemswDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----


BinaryData
====

X.509 kimlik doğrulama yöntemini yapılandırma

Güvenilen CA sertifikası içeri aktarıldıktan sonra, Bir BrokerAuthentication kaynağına kimlik doğrulama yöntemi olarak ekleyerek X.509 istemci kimlik doğrulamasını etkinleştirin. Bu kaynağın TLS özellikli bir dinleyici bağlantı noktasına bağlı olduğundan emin olun.

Azure portalında IoT İşlemleri örneğinize gidin.
Bileşenler'in altında MQTT Aracısı'ni seçin.
Kimlik Doğrulaması sekmesini seçin.
Mevcut bir kimlik doğrulama ilkesini seçin veya yeni bir ilke oluşturun.
Yöntem ekle'yi seçerek yeni bir yöntem ekleyin.
Açılan listeden X.509 yöntem türünü seçin ve ardından Yöntemi yapılandırmak için Ayrıntılar ekle'yi seçin.
X.509 kimlik doğrulama ayrıntıları bölmesinde, JSON biçimini kullanarak güvenilen CA sertifikası ConfigMap adını belirtin.
```
{
    "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>"
}
```
değerini, güvenilen CA sertifikasını içeren ConfigMap adıyla değiştirin <TRUSTED_CA_CONFIGMAP> . Örneğin, "trustedClientCaCert": "client-ca".
İsteğe bağlı olarak, X.509 sertifikalarını kullanan istemciler için yetkilendirme öznitelikleri ekleyin. Daha fazla bilgi edinmek için bkz . Yetkilendirme için sertifika öznitelikleri.
Değişiklikleri kaydetmek için Uygula'yı seçin.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'
param trustedCaConfigMap string = '<TRUSTED_CA_CONFIGMAP>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'X509'
        x509Settings: {
          trustedClientCaCert: trustedCaConfigMap
          // authorizationAttributes: {
            //// Optional authorization attributes
            //// See the next section for more information
          // }
        }
      }
    ]
  }
}

değerini, güvenilen CA sertifikasını içeren ConfigMap adıyla değiştirin <TRUSTED_CA_CONFIGMAP> . Örneğin, client-ca.

Azure CLI kullanarak Bicep dosyasını dağıtın.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

spec:
  authenticationMethods:
    - method: X509
      x509Settings:
        trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
        # authorizationAttributes:
          ## Optional authorization attributes
          ## See the next section for more information

değerini, güvenilen CA sertifikasını içeren ConfigMap adıyla değiştirin <TRUSTED_CA_CONFIGMAP> . Örneğin, client-ca.

İsteğe bağlı: Yetkilendirme için sertifika öznitelikleri

X.509 öznitelikleri, istemcileri sertifika özelliklerine göre yetkilendirmek için BrokerAuthentication kaynağında belirtilebilir. Öznitelikler alanında authorizationAttributes tanımlanır.

Örneğin:

Azure portalında X.509 kimlik doğrulama yöntemini yapılandırırken, X.509 kimlik doğrulama ayrıntıları bölmesine JSON biçiminde yetkilendirme özniteliklerini ekleyin.

{
  "trustedClientCaCert": "<TRUSTED_CA_CONFIGMAP>",
  "authorizationAttributes": {
    "root": {
      "subject": "CN = Contoso Root CA Cert, OU = Engineering, C = US",
      "attributes": {
        "organization": "contoso"
      }
    },
    "intermediate": {
      "subject": "CN = Contoso Intermediate CA",
      "attributes": {
        "city": "seattle",
        "foo": "bar"
      }
    },
    "smartfan": {
      "subject": "CN = smart-fan",
      "attributes": {
        "building": "17"
      }
    }
  }
}

x509Settings: {
  trustedClientCaCert: '<TRUSTED_CA_CONFIGMAP>'
  authorizationAttributes: {
    root: {
      subject: 'CN = Contoso Root CA Cert, OU = Engineering, C = US'
      attributes: {
        organization: 'contoso'
      }
    }
    intermediate: {
      subject: 'CN = Contoso Intermediate CA'
      attributes: {
        city: 'seattle'
        foo: 'bar'
      }
    }
    smartfan: {
      subject: 'CN = smart-fan'
      attributes: {
        building: '17'
      }
    }
  }
}

x509Settings:
  trustedClientCaCert: <TRUSTED_CA_CONFIGMAP>
  authorizationAttributes:
    root:
      subject = "CN = Contoso Root CA Cert, OU = Engineering, C = US"
      attributes:
        organization = contoso
    intermediate:
      subject = "CN = Contoso Intermediate CA"
      attributes:
        city = seattle
        foo = bar
    smart-fan:
      subject = "CN = smart-fan"
      attributes:
        building = 17

Bu örnekte, kök CA tarafından ayırt edici ada veya ayırt edici ada CN = Contoso Root CA Cert, OU = Engineering, C = US sahip ara CA CN = Contoso Intermediate CA tarafından verilen bir sertifikaya sahip olan her istemci listelenen öznitelikleri alır. Buna ek olarak, akıllı fan istemci sertifikası ona özgü öznitelikleri alır.

Öznitelikler için eşleştirme her zaman yaprak istemci sertifikasından başlar ve ardından zincir boyunca gider. Öznitelik ataması ilk eşleşmeden sonra durur. Önceki örnekte, ara sertifikaya CN = Contoso Intermediate CAsahip olsa smart-fan bile ilişkili öznitelikleri almaz.

Yetkilendirme kuralları, bu özniteliklere sahip X.509 sertifikaları kullanılarak istemcilere uygulanabilir. Daha fazla bilgi edinmek için bkz . X.509 kimlik doğrulamasını kullanan istemcileri yetkilendirme.

Dinleyici bağlantı noktası için X.509 kimlik doğrulamasını etkinleştirme

Güvenilen CA sertifikasını içeri aktardıktan ve BrokerAuthentication kaynağını yapılandırdıktan sonra tls özellikli dinleyici bağlantı noktasına bağlayın. X.509 kimlik doğrulaması istemci sertifikası doğrulaması için TLS'ye bağlı olduğundan bu adım önemlidir.

TLS özellikli dinleyici bağlantı noktasını almak için bkz. Bağlantı noktası için TLS el ile sertifika yönetimini etkinleştirme ve Bağlantı noktası için TLS otomatik sertifika yönetimini etkinleştirme.

Not

Aracı dinleyici bağlantı noktasında TLS'nin etkinleştirilmesi, aracının TLS şifrelemesi için bir sunucu sertifikası kullandığı anlamına gelir. İstemciler bu bağlantı noktasına bağlandığında, sertifikayı güven depolarında imzalayan CA sertifikasına sahip olarak sunucu sertifikasına güvenmeleri gerekir. Bu işlem, güven dağıtımı veya güven paketleme olarak bilinir. Sunucu doğrulaması ile istemci doğrulaması arasındaki farkı anlamak önemlidir:

İstemci doğrulaması: MQTT aracısı (sunucu), X.509 istemci kimlik doğrulaması için alanında belirtilen güvenilen CA sertifikasına karşı istemci sertifikasını trustedClientCaCert denetler.
Sunucu doğrulaması: İstemciler (mosquitto veya MQTTX gibi), MQTT aracısının sunucu sertifikasını güven depolarındaki güvenilen CA sertifikasına karşı denetler. Mosquitto istemcileri için, CA sertifika dosyasını belirtmek için parametresini kullanın --cafile . MQTTX için ca sertifikasını ayarlardaki güven deposuna ekleyin.

X.509 kimlik doğrulamasını etkinleştirdikten sonra, istemcilerin sunucu tarafı CA sertifikasını kendi güven depolarına alarak aracının sunucu sertifikasına güvendiğinden emin olun. Sunucu tarafı CA sertifikasına güvenmeyi, alanda belirtilen trustedClientCaCert istemci kimlik doğrulaması için kullanılan istemci tarafı CA sertifikasıyla karıştırmayın.

Tam bir örnek için bkz . Öğretici: TLS, X.509 istemci kimlik doğrulaması ve öznitelik tabanlı erişim denetimi (ABAC) yetkilendirmesi.

Mosquitto istemcisini X.509 istemci sertifikası ile MQTT aracısına bağlama

Mosquitto gibi bir istemcinin TLS ve X.509 istemci kimlik doğrulaması ile MQTT aracısına bağlanabilmesi için iki dosyaya ihtiyacı vardır.

--cert parametresi, istemci sertifikası PEM dosyasını belirtir. Bu dosya, MQTT aracısının tam sertifika zincirini oluşturmasına yardımcı olacak ara sertifikaları da içermelidir.
--key parametresi istemci özel anahtar PEM dosyasını belirtir.

MQTT aracısı TLS sunucu sertifikasını vermek için otomatik olarak imzalanan bir CA sertifikası --cafile kullandığı durumlarda parametresi gereklidir. Bu dosya, mosquitto istemcisinin TLS üzerinden bağlanırken aracının sunucu sertifikasını doğrulamak için kullandığı CA sertifikasını (güven paketi olarak da bilinir) içerir. MQTT aracısının sunucu sertifikasının vereni sistem kök deposunun (iyi bilinen genel CA'lar gibi) --cafile bir parçasıysa, parametresi atlanabilir.

Örneğin:

mosquitto_pub -q 1 -t hello -d -V mqttv5 -m world -i thermostat \
-h "<BROKER_HOST>" \
--cert thermostat_cert.pem \
--key thermostat_key.pem \
--cafile ca.pem

MQTT aracısı X.509 istemci kimlik doğrulama akışını anlama

X.509 istemci kimlik doğrulama akışının diyagramı.

İstemci kimlik doğrulaması için adımlar şunlardır:

X.509 istemci kimlik doğrulaması açık olduğunda, MQTT aracısının yapılandırılmış güvenilen sertifikalarından birine kök kökünü alan bir sertifika zinciri oluşturmasına izin vermek için, bağlantı istemcilerinin bir istemci sertifikası ve herhangi bir ara sertifika sunması gerekir.
Yük dengeleyici, iletişimi ön uç aracılarından birine yönlendirir.
Ön uç aracısı istemci sertifikasını aldıktan sonra, yapılandırılan sertifikalardan birine kökünü oluşturan bir sertifika zinciri oluşturmaya çalışır. Ön uç aracısı bir zinciri başarıyla oluşturup sunulan zincir doğrulanırsa TLS el sıkışmasını tamamlar. Bağlanan istemci, TLS kanalı üzerinden ön uçta MQTT paketleri gönderebilir.
TLS kanalı açık, ancak istemci kimlik doğrulaması veya yetkilendirmesi henüz tamamlanmadı.
İstemci daha sonra MQTT aracısına bir CONNECT paketi gönderir.
CONNECT paketi yeniden bir ön uça yönlendirilir.
Ön uç, CONNECT paketinden gelen kimlik doğrulama verileri ve TLS el sıkışması sırasında sunulan istemci sertifika zinciri gibi istemcinin şu ana kadar sunduğu tüm kimlik bilgilerini toplar.
Ön uç bu kimlik bilgilerini kimlik doğrulama hizmetine gönderir. Kimlik doğrulama hizmeti sertifika zincirini bir kez daha denetler ve zincirdeki tüm sertifikaların konu adlarını toplar.
Kimlik doğrulama hizmeti, bağlanan istemcilerin sahip olduğu öznitelikleri belirlemek için yapılandırılmış yetkilendirme kurallarını kullanır. Bu öznitelikler, CONNECT paketinin kendisi de dahil olmak üzere istemcinin hangi işlemleri yürütebileceğini belirler.
Kimlik doğrulama hizmeti, kararı ön uç aracısına döndürür.
Ön uç aracısı istemci özniteliklerini ve bağlanmasına izin verilip verilmediğini bilir. Bu durumda MQTT bağlantısı tamamlanır ve istemci, yetkilendirme kuralları tarafından belirlenen MQTT paketlerini gönderip almaya devam edebilir.

Kubernetes Hizmet Hesabı Belirteçleri

Kubernetes Hizmet Hesabı Belirteçleri (STS), Kubernetes Hizmet Hesapları ile ilişkilendirilmiş JSON Web Belirteçleridir. İstemciler, kimliklerini doğrulamak için MQTT aracısına SATs sunar.

MQTT aracısı, Kubernetes'in yeni hizmet hesabı belirteçleri hakkında GKE kullanıcılarının bilmesi gerekenler gönderisinde ayrıntılı olarak yer alan bağlı hizmet hesabı belirteçlerini kullanır. Gönderinin önemli özellikleri şunlardır:

Kubernetes 1.13'te başlatılan ve 1.21'de varsayılan biçim haline gelen bağlı belirteçler, eski belirteçlerin sınırlı işlevlerinin tümünü ve daha fazlasını ele alır:

Belirteçleri çalmak ve kötüye kullanmak daha zordur; bunlar zamana bağlı, izleyiciye bağlı ve nesneye bağlı.
Standartlaştırılmış bir biçimi benimserler: Tam OIDC Bulma özelliğine sahip OpenID Connect (OIDC), hizmet sağlayıcılarının bunları kabul etmelerini kolaylaştırır.
Bunlar, kubelet tarafından yansıtılan yeni birim türü kullanılarak podlara daha güvenli bir şekilde dağıtılır.

Aracı, Kubernetes Token Review API'sini kullanarak belirteçleri doğrular. Belirtmek audiences için Kubernetes TokenRequestProjection özelliğini etkinleştirin (1.21'den bu yana varsayılan). Bu özellik etkinleştirilmediyse, SATs kullanılamaz.

Servis hesabı oluşturma

SATs oluşturmak için önce bir hizmet hesabı oluşturun. Aşağıdaki komut adlı mqtt-clientbir hizmet hesabı oluşturur.

kubectl create serviceaccount mqtt-client -n azure-iot-operations

İsteğe bağlı: Yetkilendirme için öznitelik ekleme

SAT aracılığıyla kimlik doğrulaması yapılan istemcilerin, isteğe bağlı olarak hizmet hesaplarına yetkilendirme ilkeleriyle kullanılacak özniteliklerle ek açıklama ekleyebilir. Bu ek açıklamaları diğerlerinden ayırt etmek için ön ek ile aio-broker-auth/ başlarlar.

kullanarak kubectl annotatebir hizmet hesabına ek açıklama ekleyebilirsiniz:

kubectl annotate serviceaccount <SERVICE_ACCOUNT_NAME> aio-broker-auth/<ATTRIBUTE>=<VALUE> -n azure-iot-operations

Ek açıklamaları hizmet hesabı bildirim dosyasına da ekleyebilirsiniz:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: <SERVICE_ACCOUNT_NAME>
  namespace: azure-iot-operations
  annotations:
    aio-broker-auth/<ATTRIBUTE_1>: <VALUE_1>
    aio-broker-auth/<ATTRIBUTE_2>: <VALUE_2>

Daha fazla bilgi edinmek için bkz . Kubernetes Hizmet Hesabı Belirteçlerini kullanan istemcileri yetkilendirme.

Hizmet Hesabı Belirteci (SAT) kimlik doğrulamasını etkinleştirme

authenticationMethods Geçerli bir kimlik doğrulama yöntemi olarak belirtmek ServiceAccountToken için BrokerAuthentication kaynağındaki ayarı değiştirin. audiences, belirteçler için geçerli hedef kitlelerin listesini belirtir. MQTT aracı hizmetini tanımlayan benzersiz değerler seçin. En az bir hedef kitle belirtmeniz ve tüm SAT'lerin belirtilen hedef kitlelerden biriyle eşleşmesi gerekir.

Azure portalında IoT İşlemleri örneğinize gidin.
Bileşenler'in altında MQTT Aracısı'ni seçin.
Kimlik Doğrulaması sekmesini seçin.
Mevcut bir kimlik doğrulama ilkesini seçin veya yeni bir ilke oluşturun.
Yöntem ekle'yi seçerek yeni bir yöntem ekleyin.
Açılan listeden Kubernetes SAT yöntemini seçin ve ardından Yöntemi yapılandırmak için Ayrıntı ekle'yi seçin.

MQTT aracısı SAT kimlik doğrulama yöntemini ayarlamak için Azure portalını kullanan ekran görüntüsü.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'ServiceAccountToken'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

Azure CLI kullanarak Bicep dosyasını dağıtın.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

spec:
  authenticationMethods:
    - method: ServiceAccountToken
      serviceAccountTokenSettings:
        audiences:
        - aio-internal
        - my-audience

değişikliklerinizi ile kubectl applyuygulayın. Değişikliklerin geçerlilik kazanması birkaç dakika sürebilir.

SAT kimlik doğrulamayı test edin

SAT kimlik doğrulaması, MQTT v5 gelişmiş kimlik doğrulama alanlarını kullanır. İstemcinin gelişmiş kimlik doğrulama yöntemini olarak K8S-SAT ve gelişmiş kimlik doğrulama verilerini belirteci olarak ayarlaması gerekir.

Örneğin mosquitto kullanma (kısa süre için atlanan bazı alanlar):

mosquitto_pub ... -D CONNECT authentication-method 'K8S-SAT' -D CONNECT authentication-data <TOKEN>

Burada hizmet <TOKEN> hesabı belirteci yer alır. Test belirteci almak için şunu çalıştırın:

kubectl create token <SERVICE_ACCOUNT> -n azure-iot-operations --audience <AUDIENCE>

Burada, <SERVICE_ACCOUNT> oluşturduğunuz hizmet hesabının adıdır ve <AUDIENCE> BrokerAuthentication kaynağında yapılandırılan hedef kitlelerden biridir.

Kubernetes podunu SAT kimlik doğrulamasını kullanacak şekilde yapılandırma örneği için bkz . Küme içindeki varsayılan dinleyiciye bağlanma.

Pod yapılandırmasında, serviceAccountName içindeki alanının kullanılan belirteçle ilişkili hizmet hesabıyla eşleşmesi ve serviceAccountToken.audience alanın BrokerAuthentication kaynağında yapılandırılanlardan biri audiences olması gerekir.

Hizmet hesabı belirteçlerini yenileme

Hizmet hesabı belirteçleri sınırlı bir süre için geçerlidir ve ile expirationSecondsyapılandırılır. Ancak Kubernetes , süresi dolmadan önce belirteci otomatik olarak yeniler. Belirteç arka planda yenilenir ve istemcinin yeniden getirmek için başka bir şey yapması gerekmez.

Örneğin, istemci, test SAT kimlik doğrulaması örneğinde olduğu gibi birim olarak bağlanmış belirteci kullanan bir pod ise, en son belirteç aynı yolda /var/run/secrets/tokens/broker-satkullanılabilir. İstemci, yeni bir bağlantı oluştururken en son belirteci getirebilir ve kimlik doğrulaması için kullanabilir. İstemci ayrıca en son belirteci getirerek ve bağlantıyı yeniden deneyerek MQTT yetkisiz hatalarını işlemek için bir mekanizmaya sahip olmalıdır.

Özel kimlik doğrulaması

Özel kimlik doğrulaması ile istemci kimlik doğrulamasını sağlanan kimlik doğrulama yöntemlerinin ötesine genişletin. Api'ye bağlı olduğu sürece hizmet herhangi bir şey olabileceğinden eklenebilir .

Bir istemci özel kimlik doğrulaması etkinken MQTT aracısına bağlandığında, aracı istemcinin kimlik bilgileriyle özel bir kimlik doğrulama sunucusuna bir HTTPS isteği gönderir. Ardından sunucu, istemcinin yetkilendirme öznitelikleri de dahil olmak üzere onay veya reddetme ile yanıt verir.

Özel kimlik doğrulama hizmeti oluşturma

Özel kimlik doğrulama sunucusu, MQTT aracısından ayrı olarak uygulanır ve dağıtılır.

GitHub'da örnek bir özel kimlik doğrulama sunucusu ve yönergeler bulunur. Bu örneği, kendi özel kimlik doğrulama mantığınızı uygulamak için şablon olarak ve başlangıç noktası olarak kullanın.

API

MQTT aracısı ile özel kimlik doğrulama sunucusu arasındaki API, özel kimlik doğrulaması için API belirtimini izler. OpenAPI belirtimi GitHub'da kullanılabilir.

TLS şifrelemesi ile HTTPS gereklidir

MQTT aracısı, hassas istemci kimlik bilgilerini içeren istekleri özel kimlik doğrulama sunucusuna gönderir. Bu kimlik bilgilerini korumak için, MQTT aracısı ile özel kimlik doğrulama sunucusu arasındaki iletişim TLS ile şifrelenmelidir.

Özel kimlik doğrulama sunucusunun bir sunucu sertifikası sunması ve MQTT aracısının sunucu sertifikasını doğrulamak için güvenilen bir kök CA sertifikasına sahip olması gerekir. İsteğe bağlı olarak, özel kimlik doğrulama sunucusu, MQTT aracısının kimliğini doğrulamak için bir istemci sertifikası sunmayı gerektirebilir.

Dinleyici için özel kimlik doğrulamasını etkinleştirme

authenticationMethods Geçerli bir kimlik doğrulama yöntemi olarak belirtmek Custom için BrokerAuthentication kaynağındaki ayarı değiştirin. Ardından, özel bir kimlik doğrulama sunucusuyla iletişim kurmak için gereken parametreleri belirtin.

Azure portalında IoT İşlemleri örneğinize gidin.
Bileşenler'in altında MQTT Aracısı'ni seçin.
Kimlik Doğrulaması sekmesini seçin.
Mevcut bir kimlik doğrulama ilkesini seçin veya yeni bir ilke oluşturun.
Yöntem ekle'yi seçerek yeni bir yöntem ekleyin.
Açılan listeden Özel yöntemini seçin ve ardından Yöntemi yapılandırmak için Ayrıntı ekle'yi seçin.

param aioInstanceName string = '<AIO_INSTANCE_NAME>'
param customLocationName string = '<CUSTOM_LOCATION_NAME>'
param policyName string = '<POLICY_NAME>'

resource aioInstance 'Microsoft.IoTOperations/instances@2024-11-01' existing = {
  name: aioInstanceName
}

resource customLocation 'Microsoft.ExtendedLocation/customLocations@2021-08-31-preview' existing = {
  name: customLocationName
}

resource defaultBroker 'Microsoft.IoTOperations/instances/brokers@2024-11-01' existing = {
  parent: aioInstance
  name: 'default'
}

resource myBrokerAuthentication 'Microsoft.IoTOperations/instances/brokers/authentications@2024-11-01' = {
  parent: defaultBroker
  name: policyName
  extendedLocation: {
    name: customLocation.id
    type: 'CustomLocation'
  }
  properties: {
    authenticationMethods: [
      {
        method: 'Custom'
        serviceAccountTokenSettings: {
          audiences: [
            'aio-internal'
            'my-audience'
          ]
        }
      }
    ]
  }
}

Azure CLI kullanarak Bicep dosyasını dağıtın.

az deployment group create --resource-group <RESOURCE_GROUP> --template-file <FILE>.bicep

Bu örnekte tüm olası parametreler gösterilir. Tam olarak gereken parametreler her özel sunucunun gereksinimlerine bağlıdır.

spec:
  authenticationMethods:
    - method: Custom
      customSettings:
        # Endpoint for custom authentication requests. Required.
        endpoint: https://auth-server-template
        # Optional CA certificate for validating the custom authentication server's certificate.
        caCertConfigMap: custom-auth-ca
        # Authentication between MQTT broker with the custom authentication server.
        # The broker may present X.509 credentials or no credentials to the server.
        auth:
          x509:
            secretRef: custom-auth-client-cert
            namespace: azure-iot-operations
        # Optional additional HTTP headers that the broker will send to the
        # custom authentication server.
        headers:
          header_key: header_value

Kimlik doğrulamayı devre dışı bırakma

Test için, aracı dinleyici bağlantı noktası için kimlik doğrulamasını devre dışı bırakabilirsiniz. Üretim ortamları için kimlik doğrulamasının devre dışı bırakılması önerilmez.

Azure portalında IoT İşlemleri örneğinize gidin.
Bileşenler'in altında MQTT Aracısı'ni seçin.
Listeden düzenlemek istediğiniz aracı dinleyicisini seçin.
Kimlik doğrulamasını devre dışı bırakmak istediğiniz bağlantı noktasında, kimlik doğrulaması açılan listesinde Hiçbiri'ni seçin.

Kimlik bilgilerinin süresi dolduktan sonra istemcilerin bağlantısı kesilir

Kimlik bilgilerinin süresi dolduğunda MQTT aracısı istemcilerin bağlantısını keser. Kimlik bilgisi süre sonu MQTT aracısı ön uçlarına bağlanan tüm istemciler için geçerli olduktan sonra bağlantıyı kes:

SAT'lerinin süresi dolduğunda, SAT'lerle kimliği doğrulanmış istemcilerin bağlantısı kesilir
X.509 ile kimlik doğrulaması yapılan istemcilerin, istemci sertifikalarının süresi dolduğunda bağlantısı kesilir
Özel kimlik doğrulaması ile kimlik doğrulaması yapılan istemciler, özel kimlik doğrulama sunucusundan döndürülen süre sonu süresine göre bağlantıyı keser.

Bağlantı kesildiğinde istemcinin ağ bağlantısı kapatılır. İstemci bir MQTT DISCONNECT paketi almaz, ancak aracı istemcinin bağlantısını kestiğini belirten bir ileti günlüğe kaydeder.

SAT'ler ve özel kimlik doğrulamasıyla kimliği doğrulanmış MQTT v5 istemcileri, ilk kimlik bilgilerinin süresi dolmadan önce yeni bir kimlik bilgileriyle yeniden kimlik doğrulaması yapabilir. X.509 istemcileri yeniden kimlik doğrulaması yapamaz ve kimlik doğrulaması TLS katmanında yapıldığından bağlantıyı yeniden kurması gerekir.

İstemciler, nedeni ReAuthile bir MQTT v5 AUTH paketi göndererek yeniden kimlik doğrulaması yapabilir.

SAT istemcileri , data: <token>alanlarına method: K8S-SATsahip bir AUTH istemcisi gönderir. Özel kimlik doğrulama istemcileri, yöntemi ve veri alanını özel kimlik doğrulama sunucusunun gerektirdiği şekilde ayarlar.

Başarılı yeniden kimlik doğrulaması, istemcinin kimlik bilgisi süre sonunu yeni kimlik bilgilerinin süre sonu süresiyle güncelleştirir ve aracı bir Başarılı Kimlik Doğrulama paketiyle yanıt verir. Özel kimlik doğrulama sunucusunun kullanılamaması gibi geçici sorunlar nedeniyle kimlik doğrulaması başarısız oldu, aracının ContinueAuthentication AUTH paketiyle yanıt vermesine neden oluyor. İstemci daha sonra yeniden deneyebilir. Diğer kimlik doğrulama hataları, aracının bir DISCONNECT paketi göndermesine ve istemcinin ağ bağlantısını kapatmasına neden olur.

BrokerListener kaynağı hakkında
BrokerListener için yetkilendirmeyi yapılandırma
Öğretici: TLS, X.509 istemci kimlik doğrulaması ve öznitelik tabanlı erişim denetimi (ABAC) yetkilendirmesi

Aracılığıyla paylaş

MQTT aracısı kimlik doğrulamasını yapılandırma

BrokerListener ve BrokerAuthentication'ı bağlama

Varsayılan BrokerAuthentication kaynağı

Kimlik doğrulama akışı

Kimlik doğrulama yöntemini yapılandırma

X.509

Güvenilen CA sertifikası alma

Güvenilen CA sertifikalarını içeri aktarma

X.509 kimlik doğrulama yöntemini yapılandırma

İsteğe bağlı: Yetkilendirme için sertifika öznitelikleri

Dinleyici bağlantı noktası için X.509 kimlik doğrulamasını etkinleştirme

Mosquitto istemcisini X.509 istemci sertifikası ile MQTT aracısına bağlama

MQTT aracısı X.509 istemci kimlik doğrulama akışını anlama

Kubernetes Hizmet Hesabı Belirteçleri

Servis hesabı oluşturma

İsteğe bağlı: Yetkilendirme için öznitelik ekleme

Hizmet Hesabı Belirteci (SAT) kimlik doğrulamasını etkinleştirme

SAT kimlik doğrulamayı test edin

Hizmet hesabı belirteçlerini yenileme

Özel kimlik doğrulaması

Özel kimlik doğrulama hizmeti oluşturma

API

TLS şifrelemesi ile HTTPS gereklidir

Dinleyici için özel kimlik doğrulamasını etkinleştirme

Kimlik doğrulamayı devre dışı bırakma

Kimlik bilgilerinin süresi dolduktan sonra istemcilerin bağlantısı kesilir

Geri Bildirim

Ek kaynaklar

Aracılığıyla paylaş

MQTT aracısı kimlik doğrulamasını yapılandırma

BrokerListener ve BrokerAuthentication'ı bağlama

Varsayılan BrokerAuthentication kaynağı

Kimlik doğrulama akışı

Kimlik doğrulama yöntemini yapılandırma

X.509

Güvenilen CA sertifikası alma

Güvenilen CA sertifikalarını içeri aktarma

X.509 kimlik doğrulama yöntemini yapılandırma

İsteğe bağlı: Yetkilendirme için sertifika öznitelikleri

Dinleyici bağlantı noktası için X.509 kimlik doğrulamasını etkinleştirme

Mosquitto istemcisini X.509 istemci sertifikası ile MQTT aracısına bağlama

MQTT aracısı X.509 istemci kimlik doğrulama akışını anlama

Kubernetes Hizmet Hesabı Belirteçleri

Servis hesabı oluşturma

İsteğe bağlı: Yetkilendirme için öznitelik ekleme

Hizmet Hesabı Belirteci (SAT) kimlik doğrulamasını etkinleştirme

SAT kimlik doğrulamayı test edin

Hizmet hesabı belirteçlerini yenileme

Özel kimlik doğrulaması

Özel kimlik doğrulama hizmeti oluşturma

API

TLS şifrelemesi ile HTTPS gereklidir

Dinleyici için özel kimlik doğrulamasını etkinleştirme

Kimlik doğrulamayı devre dışı bırakma

Kimlik bilgilerinin süresi dolduktan sonra istemcilerin bağlantısı kesilir

İlgili içerik

Geri Bildirim

Ek kaynaklar