Kebijakan AccessControl

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Apa

Kebijakan Kontrol Akses memungkinkan Anda mengizinkan atau menolak akses ke API Anda berdasarkan alamat IP tertentu.

Meskipun Anda dapat melampirkan kebijakan ini di mana saja dalam alur proxy API, kemungkinan besar Anda ingin memeriksa alamat IP di awal alur ( Request / ProxyEndpoint / PreFlow), bahkan sebelum autentikasi atau pemeriksaan kuota.

Contoh

Nilai mask dalam contoh IPv4 berikut mengidentifikasi mana dari empat oktet (8, 16, 24, 32 bit) yang dipertimbangkan oleh aturan pencocokan saat mengizinkan atau menolak akses. Nilai defaultnya adalah 32. Lihat atribut mask di referensi Elemen untuk mengetahui informasi selengkapnya.

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="32">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="{kvm.mask.value}">{kvm.ip.value}</SourceAddress>
    </MatchRule>
    </IPRules>
</AccessControl>

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
    </IPRules>
</AccessControl>

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
       <SourceAddress mask="16">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="32">192.0.2.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="16">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
     </MatchRule>
  </IPRules>
</AccessControl>

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "ALLOW">
      <SourceAddress mask="16">198.51.100.1</SourceAddress>
      <SourceAddress mask="16">192.0.2.1</SourceAddress>
      <SourceAddress mask="16">203.0.113.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Catatan penggunaan

Selain melindungi API Anda dari IP berbahaya, kebijakan Kontrol Akses juga memberi Anda kontrol atas akses IP yang sah. Misalnya, jika Anda hanya ingin komputer di bawah kontrol perusahaan Anda mengakses API yang diekspos di lingkungan pengujian, Anda dapat mengizinkan rentang alamat IP untuk jaringan internal Anda. Developer yang bekerja dari rumah dapat mengakses API ini menggunakan VPN.

Konfigurasi dan eksekusi kebijakan Kontrol Akses melibatkan hal berikut:

• Tentukan serangkaian aturan pencocokan dengan salah satu dari dua tindakan (IZINKAN atau TOLAK) yang terkait dengan masing-masing aturan.
• Untuk setiap aturan kecocokan, tentukan alamat IP (elemen SourceAddress).
  • Lihat Cara kebijakan memilih alamat IP yang akan dievaluasi untuk menentukan alamat IP dalam pesan yang akan ditangani oleh aturan yang Anda konfigurasi.
  • Konfigurasi mask untuk setiap alamat IP. Anda mengizinkan atau menolak akses berdasarkan nilai mask pada alamat IP. Lihat Tentang penyamaran IP dengan notasi CIDR.
• Tentukan urutan pengujian aturan.
• Semua aturan pencocokan dijalankan dalam urutan yang diberikan. Jika aturan cocok, tindakan yang sesuai akan dijalankan dan aturan kecocokan berikutnya akan dilewati.
  • Jika aturan yang sama dikonfigurasi dengan tindakan IZINKAN dan TOLAK, aturan yang ditentukan terlebih dahulu dalam urutan akan dipicu dan aturan berikutnya (dengan tindakan lain) akan dilewati.

Cara kebijakan memilih alamat IP yang akan dievaluasi

Alamat IP dapat berasal dari berbagai sumber dalam permintaan. Misalnya, header pesan True-Client-IP mungkin berisi alamat IP, dan header X-Forwarded-For dapat berisi satu atau beberapa alamat IP. Bagian ini menjelaskan cara mengonfigurasi kebijakan AccessControl untuk mengevaluasi alamat IP yang tepat yang ingin Anda evaluasi.

Berikut adalah logika yang digunakan kebijakan AccessControl untuk memutuskan alamat IP mana yang akan dievaluasi:

1. Header True-Client-IP

Kebijakan ini pertama-tama memeriksa alamat IP di header True-Client-IP. Jika header berisi alamat IP yang valid, kebijakan akan mengevaluasi alamat tersebut.

2. Header X-Forwarded-For

Jika tidak ada header True-Client-IP, atau jika Anda telah menetapkan elemen <IgnoreTrueClientIPHeader> ke benar(true), kebijakan akan mengevaluasi alamat IP dalam header X-Forwarded-For.

Edge otomatis mengisi header X-Forwarded-For dengan alamat IP yang diterima dari handshake TCP eksternal terakhir (seperti IP klien atau router). Jika ada beberapa alamat IP di header, alamat tersebut kemungkinan merupakan rangkaian server yang memproses permintaan. Namun, daftar alamat juga dapat berisi alamat IP yang dipalsukan. Jadi, bagaimana kebijakan mengetahui alamat mana yang harus dievaluasi?

Konfigurasi organisasi dan konfigurasi kebijakan Anda menentukan alamat X-Forwarded-For mana yang dievaluasi oleh kebijakan.

Pertama, periksa apakah properti feature.enableMultipleXForwardCheckForACL disetel di organisasi Anda. Anda dapat menggunakan Get organization API untuk memeriksa. Lalu:

• Jika Anda tidak melihat feature.enableMultipleXForwardCheckForACL di daftar properti organisasi Anda, artinya properti tersebut disetel ke false (default). Jika properti ini disetel ke false, kebijakan akan mengevaluasi alamat terakhir di header (terlihat di alat Trace), yang merupakan alamat IP yang diterima Edge dari handshake TCP eksternal terakhir.
• Jika feature.enableMultipleXForwardCheckForACL di organisasi Anda disetel ke benar (true), konfigurasikan elemen <ValidateBasedOn> untuk menentukan alamat IP mana yang dievaluasi oleh kebijakan.

Mengubah properti feature.enableMultipleXForwardCheckForACL

Administrator Organisasi Edge dapat menggunakan Update organization properties API untuk menetapkan properti feature.enableMultipleXForwardCheckForACL.

Contoh API berikut menetapkan properti di Edge untuk Private Cloud. Jika ada properti lain yang ditetapkan di organisasi Anda, pastikan untuk menyertakannya juga. Jika tidak, akun tersebut akan dihapus.

curl -u email:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <DisplayName>MyOrganization</DisplayName>
    <Properties>
        <Property name="feature.enableMultipleXForwardCheckForACL">true</Property>
        <!-- Include other existing properties as well. -->
    </Properties>
</Organization>"

Di Edge untuk Private Cloud, setelah mengubah nilai properti feature.enableMultipleXForwardCheckForACL, Anda harus memulai ulang pemroses pesan, seperti yang dijelaskan dalam Memulai/menghentikan/memulai ulang komponen individual.

Dimensi X-Forwarded-For dalam analisis Apigee

Edge Analytics menulis nilai header X-Forwarded-For ke dimensi x_forwarded_for_ip. Untuk menentukan IP klien yang membuat permintaan ke Edge, gunakan nilai dalam dimensi ax_true_client_ip atau ax_resolved_client_ip. Lihat Referensi metrik, dimensi, dan filter Analytics untuk mengetahui informasi selengkapnya.

Tentang penyamaran IP dengan notasi CIDR

Notasi CIDR (Classless Inter-Domain Routing) adalah cara untuk menunjukkan rentang alamat IP melalui masking. Hal ini berlaku untuk IPv4 dan IPv6. Berikut cara kerjanya. Kita akan menggunakan IPv4 dalam contoh untuk mempermudah.

Alamat IP adalah kelompok angka yang dipisahkan dengan titik. Dalam istilah biner, setiap grup adalah jumlah bit tertentu (8 untuk IPv4 dan 16 untuk IPv6). Alamat IPv4 198.51.100.1 terlihat seperti ini dalam biner:

11000110.00110011.01100100.00000001

Itu adalah 4 grup berukuran 8 bit, atau total 32 bit. Dengan CIDR, Anda dapat menunjukkan rentang dengan menambahkan /angka (1-32) ke alamat IP, seperti ini:

198.51.100.1/24

Dalam hal ini, 24 adalah angka yang akan Anda gunakan untuk nilai atribut mask dalam kebijakan ini.

Notasi ini berarti, "Biarkan 24 bit pertama apa adanya, bit yang tersisa dapat berupa nilai 0 hingga 255." Contoh:

Perhatikan bahwa mask terjadi di akhir grup tiga. Hal ini membuat semuanya menjadi rapi dan teratur, pada dasarnya membuat mask seperti ini: 198.51.100.*. Dalam sebagian besar kasus, menggunakan kelipatan 8 (IPv4) dan 16 (IPv6) akan memberikan tingkat masking yang Anda inginkan:

IPv4: 8, 16, 24, 32

IPv6: 16, 32, 48, 64, 80, 96, 112, 128

Namun, Anda dapat menggunakan angka lain untuk kontrol yang lebih terperinci, yang melibatkan sedikit perhitungan biner. Berikut adalah contoh penggunaan mask 30, seperti pada 198.51.100.1/30, dengan 1 terakhir adalah 00000001 dalam biner:

Dalam contoh ini, dengan konfigurasi yang ditetapkan ke <SourceAddress mask="30">198.51.100.1</SourceAddress>, IP berikut akan diizinkan (atau ditolak, bergantung pada aturan Anda):

• 198.51.100.0
• 198.51.100.1
• 198.51.100.2
• 198.51.100.3

Referensi elemen

Referensi elemen menjelaskan elemen dan atribut kebijakan Kontrol Akses.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control 1</DisplayName>
    <IPRules noRuleMatchAction = "ALLOW">
        <MatchRule action = "ALLOW">
            <SourceAddress mask="32">198.51.100.1</SourceAddress>
        </MatchRule>
        <MatchRule action = "DENY">
            <SourceAddress mask="24">198.51.100.1</SourceAddress>
        </MatchRule>
    </IPRules>
    <ValidateBasedOn>X_FORWARDED_FOR_ALL_IP</ValidateBasedOn>
</AccessControl>

Atribut <AccessControl>

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1"> 

Tabel berikut menjelaskan atribut yang umum untuk semua elemen induk kebijakan:

&lt;DisplayName&gt; elemen

Gunakan selain atribut name untuk memberi label kebijakan di editor proxy UI dengan nama natural language yang berbeda.

<DisplayName>Policy Display Name</DisplayName>

Elemen <IgnoreTrueClientIPHeader>

Jika Anda menyetelnya ke benar (true), kebijakan akan mengabaikan header True-Client-IP dan mengevaluasi alamat IP di header X-Forwarded-For, mengikuti perilaku evaluasi X-Forwarded-For yang telah Anda konfigurasi.

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

Elemen <IPRules>

Elemen induk yang berisi aturan yang mengizinkan atau menolak alamat IP. Atribut noRuleMatchAction memungkinkan Anda menentukan cara menangani alamat IP yang tidak tercakup oleh aturan pencocokan Anda.

<IPRules noRuleMatchAction = "ALLOW">

Atribut

Elemen <IPRules>/<MatchRule>

Tindakan yang akan diambil (izinkan atau tolak akses) jika alamat IP cocok dengan SourceAddress(es) yang Anda tentukan.

<IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
        <SourceAddress mask="32">198.51.100.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
        <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
</IPRules>

Atribut

Elemen <IPRules>/<MatchRule>/<SourceAddress>

Rentang alamat IP klien.

Nilai yang valid: Alamat IP yang valid (notasi desimal bertitik). Untuk perilaku karakter pengganti, gunakan atribut mask.

<IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
        <SourceAddress mask="{variable}">198.51.100.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
        <SourceAddress mask="24">{variable}</SourceAddress>
    </MatchRule>
</IPRules>

Seperti yang ditunjukkan dalam contoh sebelumnya, elemen SourceAddress juga mendukung Template pesan untuk atribut mask atau alamat IP, yang berarti Anda dapat menetapkan nilai menggunakan variabel yang saat ini tersedia dalam alur proxy API.

Misalnya, Anda dapat menyimpan alamat IP di peta nilai kunci (KVM) dan menggunakan kebijakan KeyValueMapOperations untuk mengambil alamat IP dan menetapkannya ke variabel (seperti kvm.ip.value). Kemudian, Anda dapat menggunakan variabel tersebut untuk alamat IP:

<SourceAddress mask="24">{kvm.ip.value}</SourceAddress>

Menetapkan masker dan/atau alamat IP dengan variabel memberi Anda fleksibilitas untuk mengubah nilai saat runtime tanpa harus mengubah dan men-deploy ulang proxy API.

Atribut

Elemen <ValidateBasedOn>

Jika header HTTP X-Forwarded-For berisi beberapa alamat IP, gunakan elemen ValidateBasedOn ini untuk mengontrol alamat IP mana yang dievaluasi.

Gunakan pendekatan ini untuk mengevaluasi alamat IP hanya jika Anda yakin dengan validitas alamat IP yang ingin Anda evaluasi. Misalnya, jika Anda memilih untuk mengevaluasi semua alamat IP di header X-Forwarded-For, Anda harus dapat memercayai validitas alamat tersebut, dan/atau menyiapkan aturan TOLAK atau IZINKAN yang komprehensif agar hanya IP tepercaya yang dapat memanggil proxy API Anda.

Alamat IP paling kiri di header adalah milik klien, dan yang paling kanan adalah server yang meneruskan permintaan ke layanan saat ini. Alamat IP paling kanan, atau terakhir, adalah alamat yang diterima Edge dari handshake TCP eksternal terakhir.

Nilai yang Anda masukkan dalam elemen ini memungkinkan Anda menentukan apakah akan memeriksa semua alamat IP di header (default), hanya alamat IP pertama, atau hanya alamat IP terakhir.

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control 1</DisplayName>
    <IPRules noRuleMatchAction = "ALLOW">
        <MatchRule action = "DENY">
            <SourceAddress mask="32">198.51.100.1</SourceAddress>
        </MatchRule>
    </IPRules>
    <ValidateBasedOn>X_FORWARDED_FOR_ALL_IP</ValidateBasedOn>
</AccessControl>

Skema

Setiap jenis kebijakan ditentukan oleh skema XML (.xsd). Sebagai referensi, skema kebijakan tersedia di GitHub.

Referensi error

Bagian ini menjelaskan kode kesalahan dan pesan kesalahan yang dikembalikan dan variabel kesalahan yang disetel oleh Edge saat kebijakan ini memicu kesalahan. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Penanganan kesalahan.

Error runtime

Error ini dapat terjadi saat kebijakan dijalankan.

Variabel kesalahan

Variabel ini ditetapkan saat terjadi error runtime. Untuk mengetahui informasi selengkapnya, lihat Variabel khusus untuk error kebijakan.

Contoh respons kesalahan

{
   "fault":{
     "faultstring":"Access Denied for client ip : 52.211.243.3"
      "detail":{
         "errorcode":"accesscontrol.IPDeniedAccess"
      }
   }
}

Contoh aturan kesalahan

<FaultRule name="IPDeniedAccess">
    <Step>
        <Name>AM-IPDeniedAccess</Name>
        <Condition>(fault.name Matches "IPDeniedAccess") </Condition>
    </Step>
    <Condition>(acl.failed = true) </Condition>
</FaultRule>