A biztonság alapelemei közé tartozik az integritás, a bizalmasság, az azonosság és hitelesítés, az üzenethitelesítés, a munkamenet-kezelés, a jogosultságkezelés, az adatvédelem, a letagadhatatlanság és a kriptográfia. Ezen fogalmak közvetlenül befolyásolják a SOA biztonság architekturális és logikai tervét.
2.1. Integritás
Az információ integritása egy információdarabka olyan állapotára utal, amelyet nem változtattak meg illetéktelen vagy váratlan módon. Az egymással kommunikáló partnerek üzenetváltásai során küldött üzenetek integritásának megőrzése lehetővé teszi a felek számára, hogy bizonyos mértékig biztosak lehessenek abban, hogy az átvitel során az üzenet nem változott meg. Az integritási védelem azt jelenti, hogy ha egy rosszindulatú felhasználó elfog egy üzenetet, és megváltoztatja annak tartalmát, azt felfedezik.
2.2. Bizalmasság
Az információ bizalmasságán az információ jogosulatlan vagy váratlan közzétételével kapcsolatos állapotát értjük. Az adatok integritását és bizalmasságát mind átvitel során, mind pedig álló helyzetben értelmezhetjük.
Az üzenetek bizalmassága lehetővé teszi a felek számára, hogy egy bizonyos mértékig biztosak lehessenek abban, hogy – amennyiben fontos, hogy egy üzenet kényes részletei ne juthassanak más tudomására – üzeneteiket harmadik fél nem olvashatta el menet közben.
A tranziens üzenetbizalmassági védelem azt jelenti, hogy az üzenet átvitele során tartalma nem kerül rosszindulatú személyek kezére, még akkor sem, ha azok elfogják az üzenetet. A perzisztens üzenetbizalmassági mechanizmusok biztosítják az üzenet adatai (pl. hitelkártyaszám, TAJ-szám stb.) megbízhatóságának fenntartását. Ha például az üzeneteket naplózzák, a perzisztens bizalmasság biztosítja azt, hogy még ha valaki hozzá is fér egy szerver naplójához, ne tudja elolvasni az üzenet tartalmát.
A bizalmasság és az integritás fogalma rezidens információk esetén is alkalmazható. A perzisztens adatintegritást például perzisztens adatokra és kódokra is alkalmazhatjuk. Az egyes aláírási technikák biztosítják, hogy az információ nem kerül megváltoztatásra. Általánosságban minden olyan esetben szükségünk lesz integritási és bizalmassági technikákra, amikor biztosak szeretnénk lenni abban, hogy az információt nem hamisítják meg vagy olvassák el az átvitel során, avagy az adattárolóban.
2.3. Azonosság és hitelesítés
A hitelesítés (autentikáció) egy állítólagos személyazonosság ellenőrzésének folyamata. A hitelesítési folyamat egy publikus (mint pl. a felhasználói név) és egy privát (mint pl. a jelszó, amit elviekben csak a felhasználó ismer) információdarab alapján dönti el az érvényességet úgy, hogy összehasonlítja azzal, amit a rendszer ismer.
Ezeket a privát információkat hitelesítési adatoknak is nevezzük, amelyek valamilyen ismert (pl. jelszó) vagy birtokolt (pl. hardverkulcs) dolgon, vagy egy soha meg nem változó idempotens objektumon (pl. ujjlenyomat) alapulnak.
Az azonosság ellenőrzése (vagyis a sikeres hitelesítés) után az egyes rendszerek és alkalmazások a hitelesített egyedhez jogosultságokat rendelnek. Ezek a jogosultságok – melyeket gyakran jogosultsági adatoknak is nevezünk – határozzák meg, hogy az egyed mit tehet a vállalaton belül (lásd még a 8.2.6. szakaszt). Így egy hitelesített, biztonságos munkamenet környezetén belül a rendszer kikényszerítheti, hogy a hitelesített egyedek jogosultsághoz kötött kérésekkel dolgozzanak, és bizonyos esetekben mindenről, amit a hitelesített felhasználó tenni próbál, naplót vezethet.
Tekintsünk például egy rendelésteljesítési folyamat részeként használt alkalmazást. Ez az alkalmazás olyan egyéb alkalmazásokat is használhat munkájának elvégzése során, amelyek például a kiszállítások ütemtervével vagy éppen a raktáron lévő áru mennyiségének kezelésével foglalkoznak. A kiszállítások ütemezését végző alkalmazáshoz történő hozzáférés lehet korlátozott, amikor a raktárvezető csak a következő 24 óra adatait látja, az ezen túli időpontokhoz tartozó kiszállításokat csak a rendelések felvitelét végző adminisztratív alkalmazottak jogosultak látni. Hasonlóképpen, a raktáron lévő áru mennyiségének módosítását szintén auditálhatjuk, így az esetleges visszaélésekre könnyen fény derülhet. Mindkét esetben a hitelesített azonosság, a jogosultsági meghatalmazások és a felek között kialakított bizalmi kapcsolat teszi lehetővé a megfelelő tevékenységek engedélyezését vagy tiltását, és az (engedélyezett vagy tiltott) kérések naplózását.
2.4. Üzenethitelesítés
A bizalmassági és integritási technikák egyik érdekes mellékhatása, hogy amikor folyamatok és alkalmazások helyett üzenetekre alkalmazzuk őket, üzenethitelesítést biztosítanak. Az üzenethitelesítés célja, hogy megbizonyosodhassunk, az üzenet valóban attól a féltől származik, akitől mondja magát. Mindezt előzetes megegyezés során kialakított kriptográfiai technikák segítségével érhetjük el. Lényeges, hogy az üzenethitelesítés, vagyis az adat eredetének szavatolása lehetővé teszi a fogadó számára az üzenet küldőjének beazonosítását.
2.5. Munkamenet-kezelés
Egy munkamenet a hosszú távú üzenetváltásban részt vevő felek között megosztott környezet. Ahelyett, hogy minden üzenetváltás során igazolnák azonosságukat, létrehoznak egy munkamenet-környezetet a kérdéses felek
hitelesített azonosságaihoz kötődően. Munkamenet-kezelésen ennek a környezetnek a kezelését értjük, melybe beletartozik a környezet létrehozása és törlése is.
Egy munkamenet biztonságossá tétele magával vonja az egyes felek hitelesítését, olyan alkalmas tokenek létrehozását, amelyek a többszörös kérések és válaszok (vagyis tranzakciók) biztonságossá tételére használhatók, majd az adatcsere befejeztével a munkamenet során gyorstárba helyezett információk törlését is.
Egy biztonságos munkamenet állapotának karbantartása azt jelenti, hogy a sok kérés- és válaszüzenetet egy nagyobb, többüzenetes tranzakció részeként kapcsolhatjuk össze.
A munkamenet állapotának kezelése biztonsági és teljesítménybeli szempontokból egyaránt nagyon fontos. A biztonság egyik legalapvetőbb elve az, hogy a felhasználóknak előnyük származzon a számukra felajánlott biztonsági megoldásokból. Sokszor a felhasználók kényelmetlenségérzete vezet el az első biztonsági kihíváshoz:
ha minden kéréshez meg kell adniuk a hitelesítéshez szükséges adatokat (pl. felhasználói név és jelszó), akkor gyakran megtalálják annak a módját, hogy miképpen kerüljék el a biztonsági mechanizmusokat.
Az olyan mechanizmusok, mint a WS-SecureConversation és az egyszeri bejelentkezés (single sign-on), úgy tudják csökkenteni a hitelesítések darabszámát, hogy az üzleti követelményeknek továbbra is megfelelő védelmet nyújtanak.
2.6. Jogosultságkezelés
A jogosultságkezelés az a folyamat, amely során egy egyed által végrehajtható tevékenységekről születik döntés, majd ez alapján engedélyezünk vagy tiltunk bizonyos tevékenységeket. Legegyszerűbb esetben ez nem összetett kérdések megfogalmazását jelentheti: „X megteheti-e Y-t?” „Az X felhasználó hozzáférhet-e az Y erőforráshoz?”. Összetettebb esetekben azonban a döntési folyamathoz a kérésben megfogalmazott feltételek kiértékelésére is szükség lehet: „Az X felhasználó hozzáfér-e az Y erőforráshoz Z napon?”, vagy „Az X felhasználó hozzáférhet-e az Y erőforráshoz Z megszorítások mellett?”. A hozzáférésről szóló döntés kikényszerítése az a folyamat, amely gondoskodik arról, hogy a döntés eredményének megfelelően a hozzáférés biztosítva avagy tiltva legyen.
Egy egyszerű példa jogosultság megállapítására az „Átutalhat-e Zsuzsa pénzt az A számláról a B számlára?”
kérdésre adott válasz. Vannak azonban sokkal összetettebb döntések, mint az „X megteheti-e Y-t Z-vel?”.
Gyakran a kérdés megválaszolásához további információkra van szükség. Például Zsuzsa átutalásának kérdését tovább finomíthatjuk a rendszer által a munkamenet létrehozásához használt hitelesítési módszer megadásával, az „Y” pontos természetével és annak „Z”-re kifejtett hatásával. Például ha az „Y” azt jelenti, hogy „utalj át 10 000 $-t az A számláról a B számlára”, ahol a „Z” az A számla, amelynek csak 4,21 $ az egyenlege, akkor a válasz egyértelműen „Nem” kell, hogy legyen.
Egy szolgáltatásorientált architekturális minta esetén fontos megértenünk a jogosultság szemcsézettségét. A rendszer határainak biztonságossá tételét előíró paradigma alapján azt mondhatjuk, hogy a rendszernek el kell végeznie egy kezdeti hitelesítést a tartomány széléhez olyan közel, amennyire csak lehet, és az aktuális hívástól olyan távol, amennyire csak lehet. Ez a stratégia a vezérlést körökre osztja. Célszerű a hitelesítést rétegzett módon végezni, amelyben a jogosulatlan kéréseket elnyelik az alsóbb feldolgozórétegek. Ez azt jelenti, hogy a magasabb rétegekhez eljutó kérések esetén a jogos és nem jogos kérések aránya magas lesz, ami a teljesítmény és a biztonság szempontjából is hasznos.
Zsuzsa átutalási kérelmének példáján keresztül nézzük meg, hogyan lehet a hozzáférés-szabályozással kapcsolatos döntéseket rétegezni:
• „Átutalhat-e Zsuzsa pénzt?” – Igen
• „Átutalhat-e Zsuzsa pénzt az A számláról a B számlára?” – Igen
• „Átutalhat-e Zsuzsa 10 000 $-t az A számláról a B számlára?” – Igen/Talán
• „Átutalhat-e Zsuzsa 10 000 $-t az A számláról a B számlára úgy, hogy az A számla egyenlege 4,21 $?” – Nem
Vagyis az „Átutalhat-e Zsuzsa pénzt az A számláról a B számlára?” döntést felbonthatjuk, rétegezhetjük annak érdekében, hogy annál tovább finomítható legyen, minél közelebb jut a kérés a kérdéses adatokhoz.
Általánosságban a rendszer hozhat egy kezdeti döntést egy adott kérésről, pusztán az autentikált azonosság alapján. Például Zsanett – aki nem autentikált felhasználó – kérése már a vállalati hálózat határán megáll. Ahogy a kérés tovább halad a vállalati hálózatba, a döntések tovább finomíthatók.
A közvetítő rétegben, ahol a brókerek és a proxik továbbítják a kéréseket, lehet a döntéshozás következő szintje:
„Nyithat-e Márk új kereskedelmi számlát?”. Nem, mert számláját fél évre felfüggesztették, ezért csak jelentések olvasására korlátozódnak a lehetőségei. Az alkalmazás szintjén a rendszer meghozza a végső döntést az
„Átutalhat-e Zsuzsa 10 000 $-t az A számláról (egyenlege 4,21 $) a B számlára (egyenlege 2124,25 $)?”
kérdésről.
Amikor az erőforrásokat és szolgáltatásokat az üzleti partnerek számára is elérhetővé szeretnénk tenni, megvalósíthatunk egy jogosultsági szűrést mindkét oldalon. Így az üzleti partner felelősségi körébe tartozhat, hogy csak olyan kéréseket küldjön a szolgáltató felé, amelyeket az hajlandó befogadni. Vagyis ha a partner nem hajlandó egy adott árucikkre egy 10 000 db-ra szóló rendelést elfogadni, egyenként 1,25 $-os áron, akkor a megrendelő partnernek már össze sem kell állítania ezt a kérést (és persze a jogosultságokkal sem kell foglalkozni), ami így természetesen már el sem jut a szolgáltatóig.
Ez nyilvánvalóan nem jelenti azt, hogy ezzel felmentjük a szolgáltatót a jogosultsági döntések meghozása és betartatása alól. Ehelyett, az üzleti partner által kapott kérések már autorizáltak, így a szolgáltató által meghozandó döntések az „Ez az üzleti partner küldhet-e ilyen kéréseket?” és a „Ki tudom-e elégíteni a kéréseket?” típusú kérdések szintjére lépnek.
2.7. Adatvédelem
Az adatok védelme mint a jogosultságkezelés egy dimenziója, bizalmassági mechanizmusokat is magában foglal. Ez egy olyan plusz attribútum, amelyet magán az üzeneten belül elhelyezkedő adatelemekre vonatkozóan adhatunk meg. A korábbi példát alapul véve, ha rendelünk 10 000 db 1 $-os árucikket, magának a cikk árának esetleg titkosnak kellene lennie (lehet, hogy ez bizalmas információ). Épp ezért, a rendszernek szüksége van egy megfelelő titkosításra, hogy a korábbi üzenetszintű bizalmasságon túlmenően védje az adatot a jogosulatlan megtekintéstől. A vállalaton belül, miután a rendszer eltávolította az üzenetszintű bizalmassági mechanizmust, továbbra is védeni kell ezen cikkek egységárát. Ez lehetővé teszi a fogadó oldalon valaki számára, hogy tudjon róla, hogy leadtak egy rendelést – ha hozzáfér az üzenethez, miután a bizalmassági információk eltávolításra kerültek –, de nem tudja az egységárat.
Az adatvédelmi szempontokat nemcsak az ilyen jellegű (pl. versenyelőnyt vagy -hátrányt okozni képes) információk esetén kell érvényesíteni, hanem a személyes információkra vonatkozóan is, mint amilyenek pl. a TAJ-szám, a cím, az életkor vagy akár a kedvenc üdítőital, amelyek védelmére eltérő követelmények vonatkozhatnak.
2.8. Letagadhatatlanság
Az üzleti életben jogi szempontból gyakran bizonyítékra van szükség arról, hogy egy bizonyos esemény egy adott feltételrendszer mellett bekövetkezett. Mivel a cégek működése egyre inkább számítógépes rendszereken alapszik, és így nyújtanak üzleti szolgáltatásokat, ezen rendszerek feladata lesz a bizonyítékok előállítása a jogi kihívásokra válaszul. A jogosultsággal kapcsolatos döntések megbízható partnerkapcsolatok segítségével történő elosztásának egyik oka, hogy az üzleti szolgáltatásoknak bizonyítékra van szükségük a letagadhatatlanság érdekében.
A letagadhatatlanság biztosítja, hogy az üzenetet vagy kérést a küldője nem cáfolhatja meg. Például, ha egy cég 10 000 db árucikket rendel, a letagadhatatlanság garantálja, hogy a cég a későbbiekben ne tagadhassa le ezt a rendelést. Habár a valódi letagadhatatlanság elérése különösen nehéz, az egyes rendszerek digitális aláírások segítségével egy, az online tranzakciók számára elégséges letagadhatatlansági megoldást érhetnek el.
A digitális aláírás, melyet a kérelmező egy üzenetben ad ki, azt jelzi, hogy az aláíró (vagyis a kérelmező) jóváhagyta a kérést. Ez az alábbi feltételezésekre épít:
• Az aláírt információ tartalmaz egy időbélyeget, és azonosítja a kérelmezőt.
• Az aláíráshoz használt privát kulcsot csak az aláíró ismeri, ezért csak ő képes ennek a digitális aláírásnak a létrehozására. A rendszer tartalmazhat olyan rétegeket, amelyek bizonyítékot szolgáltathatnak arról, hogy valóban egyedüli entitásként ő ismeri ezt a kulcsot.
• A rendszer feltételezi, hogy a kérelmező csak olyan információt ír alá, amelyről tud, és amelyért felelősséget vállal. Ezért a későbbiekben a kérelmező nem jöhet elő azzal, hogy annak ellenére, hogy aláírta az üzenetet, nem olvasta el vagy nem értette meg annak tartalmát.
A letagadhatatlanság köré épült üzleti politikáknak a tranzakciós környezetekben egyre nagyobb szerepük van, és segítségükkel olyan megbízhatóságon alapuló kapcsolat építhető fel, amelynek az elektronikus rendszerek a teljes kérelmező-szolgáltató környezetben jogosultsági döntéseket hozhatnak meg.
2.9. Kriptográfia
Az elektronikus információk integritásának és bizalmasságának megóvására kriptográfiai eszközöket használhatunk. Ez egy összetett matematikai témakör, de bőven van szakirodalma. Röviden, a kódolás nem más, mint egy információ egyik formátumból egy másikba történő konverziója egy matematikai transzformáció segítségével. A transzformáció bemenete egy kulcs és a transzformálandó üzenet, eredménye pedig a kódolt üzenet. A dekódolás az a transzformáció, amely a kódolt üzenetből egy másik kulcs segítségével visszaállítja az eredeti üzenetet.
A kódolás alapulhat szimmetrikus vagy aszimmetrikus kulcsokon is. A szimmetrikus kulcsokat használó rendszerek ugyanazt a kulcsot használják a kódolás és a dekódolás során is. Ilyenek például az osztott kulcsú rendszerek, amikor a felek egy közös kulccsal rendelkeznek, amelyet mindketten titokban tartanak mások előtt.
Egy aszimmetrikus kulcsokkal operáló rendszer egy kulccsal végzi a kódolást, és egy ehhez kapcsolódó, ámde mégis eltérő kulccsal a dekódolást, vagyis az eredeti üzenet visszaállítását. Az ilyen rendszerek egy részében elegendő csupán az egyik kulcsot titokban tartani, a másik nyilvános is lehet: ezeket nyilvános kulcsú rendszereknek nevezzük.
A nyilvános kulcsú infrastruktúra technikái aszimmetrikus kulcsokon alapulnak. Ekkor a felhasználó rendelkezi egy titkos, privát kulccsal, míg partnerei számára elérhetővé tesz egy nyilvános kulcsot. A privát kulccsal kódolt információk a nyilvános kulccsal dekódolhatók, és fordítva. A kulcspárok kiadása, regisztrációja és szétszórása fontos komponense az ilyen rendszereknek, és gyakran ez a rész okozza a legtöbb problémát a telepítés során is.
A kulcspár nyilvános fele egy tanúsítványban kerül elhelyezésre, így a felhasználó nyilvános kulcsát összekötjük a személyazonosságával. Így a felhasználó saját azonosságát a privát kulcs használata segítségével fejezheti ki, amely állítást a nyilvános kulcsot ismerők leellenőrizhetnek.
A nyilvános kulcsú infrastruktúrán (PKI – public key infrastructure) alapuló technikák roppant hasznosak, hiszen megengedik a feleknek, hogy egy bizalmon alapuló infrastruktúrát alakítsanak ki úgy, hogy az egyes résztvevőknek csak a saját privát kulcsuk kezelésére kelljen összpontosítaniuk, míg azokkal a partnerekkel, akikkel bizalmi kapcsolatba szeretnének lépni, a nyilvános kulcsot tartalmazó tanúsítványt kell csak kicserélniük. Ez egy nagyon rugalmas megközelítés a sok partnerrel történő átfogó bizalmi kapcsolatok kezelésére. Ennek a megoldásnak számos előnye van, de a feleknek rendszeresen ellenőrizniük kell, hogy tanúsítványuk még mindig érvényes-e. Egy vállalatnak rendelkeznie kell olyan üzleti szabályokkal, amelyek ezt az érvényességi időtartamot szabályozzák.
Mind az osztott, mind pedig a nyilvános kulcsú rendszerek az adatok titkosítására használhatók. A kódolás védelmet nyújt az információ közzétételével szemben is: ha egy információ kódolva van, csak azok ismerhetik meg, akik képesek a dekódolására, vagyis, osztott kulcsú környezetben rendelkeznek a közös kulccsal, vagy PKI környezetben rendelkezésükre áll a nyilvános kulcs.
A teljesítmény szempontjából a nyilvános–privát kulcspárok használatának kihívása, hogy a feldolgozási teljesítmény szempontjából a nyilvános kulcsú oldalon végzett műveletek jelentősen költségesebbek, mint a privát kulcsok oldalán végrehajtottaké. Egy szimmetrikus kulcsú rendszer esetében a kódolás és dekódolás költsége általában sokkal kisebb. Azonban a nyilvános kulcsú rendszerek feldolgozási költségeinek ellenére egy ilyen rendszer működtetése olcsóbb, mint a helyettük alkalmazható sok közös kulcs kezeléséé. Mindazonáltal, nagy mennyiségű adatok kódolása során az osztott kulcsú technikákat érdemes előnyben részesíteni, az adatokhoz történő hozzáférés idejének lecsökkentése érdekében.
A nyilvános kulcsú technikákat széles körben alkalmazzák az adatintegritás és az adateredet biztosítására is.
Ezen túlmenően, a PKI technikák digitális aláírások kezelésére is használhatók. Digitális aláírás használata esetén általában nem kódolunk nagy mennyiségű adatot, hanem egy hash-függvény segítségével előállítjuk az üzenet egyedi, fix méretű reprezentációját. Ezt a hash-értéket kódoljuk, és küldjük el az üzenettel. A folyamat során az ügyfél digitálisan aláírja a védendő adatokat, a kódolt hash-érték pedig maga a digitális aláírás. Az
értéket hasonlítjuk a dekódolt aláírással (amely az eredeti hash-érték). Ha megegyeznek, akkor ez egy hiteles aláírás. A hash-függvénynek és a kriptográfiának ezen kombinációjával kapott költség alacsonyabb, mint ha a teljes üzenetet kódoltuk volna, amikor csak integritási védelemre van szükségünk.
A digitális aláírások az információ esetleges megváltoztatását is bizonyítják, vagyis fenntartják az integritást. Ha egy aláírt üzenetben módosítás történik, az aláírás érvénytelenné válik, hiszen a hash-értékek különbözni fognak. Vagyis egy érvénytelen aláírás azt jelenti, hogy az üzenetintegritás sérült.
2.10. Bizalom
Két fél biztonságos kommunikációjához közvetlen vagy közvetett módon, de biztonsági hitelesítő adatok cseréjére van szükség. Azonban mindkét félnek meg kell határoznia, hogy milyen szintű bizalmat helyez a másik féltől kapott adatokba.
A bizalom szintén a jogosultságkezelés egyik eleme, amely azonban szélesebb körben, egyedek csoportjai (pl.
felhasználók, rendszerek, alkalmazások, folyamatok stb.) között értelmezendő. A szervezetközi üzenetváltások elengedhetetlen eleme, de akár egyetlen szervezeten belül is alkalmazható (pl. osztályok vagy alhálózatok között). A bizalom segítségével az alapján alakíthatjuk ki a jogosultsági stratégiát egyedek teljes csoportjai között, hogy ők milyen interakciókban vesznek részt más csoportokkal.
Egy bizalmi tartomány meghatározza a hozzá tartozó egyedek azonosságát és természetét. Lehetőségünk van ugyanazon egyedek között különböző tartományokat is definiálni, attól függően, hogy ezek az egyedek hogyan látszanak és keverednek a tartományon belül. Egy egyszerű adatbázis például két különböző bizalmi tartományba is beletartozhat attól függően, hogy milyen más – speciális célú alkalmazásokat tartalmazó – tartományok férnek hozzá. A tartományok más tartományokat is tartalmazhatnak, például a teljes cég bizalmi tartományába az egyes különálló osztályok bizalmi tartományai tartozhatnak.
2.11. Szövetség
A tartományok közötti bizalom kialakításának magasabb absztrakciós szintjén meg kell gondolnunk, hogyan integrálhatóak különböző szolgáltatók szolgáltatásai. A szokásos megoldás szerint erre egy olyan absztrakciós szintet húzunk fel, amely a különböző rendszereket szövetségbe tömöríti. Egy ilyen szolgáltatásszövetségben több szolgáltató különféle szolgáltatásai kaphatnak helyet, és a modell lehetővé teszi, hogy a szövetségen belül alakítsuk ki a bizalmi viszonyt egyszeri be- és kijelentkezéssel (single sign-on és single sign-off), és elosztott attribútumkezelést alkalmazzunk. A szövetségek szerepe különösen fontos olyan SOA-k esetében, amelyek túlmutatnak egy szervezet határain. Tulajdonképpen egy virtuális közös biztonsági modellt alakítunk ki úgy, hogy az egyes szervezetek egyedi modelljeit egy közös referenciamodellhez társítsuk.