Paglipat sa Iba't Ibang Pinagmulan ng Seguridad ng Cognos

Kung kailangan mong muling isaayos ang isang umiiral na kapaligiran ng Cognos upang magamit ang iba't ibang mapagkukunang panlabas na seguridad (hal. Aktibo na Direktoryo, LDAP, atbp), maraming mga diskarte na maaari mong gawin. Gusto kong tawagan sila, "The Good, the Bad, and the Ugly." Bago namin tuklasin ang mga diskarte sa Mabuti, Masama, at Pangit na ito, tingnan muna natin ang ilang mga karaniwang sitwasyon na may posibilidad na humimok ng mga pagbabago sa namespace ng pagpapatotoo sa isang kapaligiran ng Cognos.

Mga Karaniwang Mga Driver sa Negosyo:

Ina-update ang Hardware o OS - Ang paggawa ng makabago BI hardware / imprastraktura ay maaaring maging isang madalas na driver. Habang ang natitirang Cognos ay maaaring tumakbo tulad ng isang champ sa iyong makinis na bagong hardware at modernong 64-bit OS, swerte mong ilipat ang iyong circa-2005 na bersyon ng Access Manager papunta sa bagong platform. Ang Access Manager (unang inilabas sa Series 7) ay isang kagalang-galang na pag-holdover mula sa mga araw na lumipas para sa maraming mga customer sa Cognos. Ito ang nag-iisang dahilan na pinananatili ng maraming mga customer ang napakalaking lumang bersyon ng Windows Server 2003. Ang pagsulat ay nasa pader para sa Access Manager nang medyo matagal. Ito ay legacy software. Ang mas maaga kang lumipat palayo dito, mas mabuti.

Pamantayan sa Application- Mga organisasyong nais na pagsamahin ang pagpapatotoo ng lahat ng kanilang mga aplikasyon laban sa isang gitnang namamahala sa direktoryo ng server ng server (hal. LDAP, AD).

Mga pagsasama-sama at Mga Pagkuha- Bumibili ang Kumpanya A ng Kumpanya B at kailangan ang kapaligiran ng Cognos ng Kumpanya B upang ituro ang direktoryo ng kumpanya ng A, nang hindi nagdudulot ng mga isyu sa kanilang umiiral na nilalaman ng BI o pagsasaayos.

Mga Divestiture ng Corporate- Ito ang kabaligtaran ng senaryo ng pagsasama, ang isang bahagi ng isang kumpanya ay naikot-ikot sa sarili nitong nilalang at kailangan ngayong ituro ang mayroon nang kapaligiran sa BI sa bagong mapagkukunan ng seguridad.

Bakit ang Namespace Migrations ay maaaring maging Magulo

Ang pagturo sa isang kapaligiran ng Cognos sa isang bagong mapagkukunan ng seguridad ay hindi kasing simple ng pagdaragdag ng bagong namesapce sa parehong mga gumagamit, pangkat, at tungkulin, pagdidiskonekta sa dating namespace, at VOILA! - lahat ng iyong mga gumagamit ng Cognos sa bagong namespace ay naitugma sa ang kanilang nilalaman. Sa katunayan, madalas kang mapunta sa isang madugong gulo sa iyong mga kamay, at narito kung bakit…

Lahat ng mga punong tagapagtaguyod ng seguridad ng Cognos (mga gumagamit, pangkat, tungkulin) ay isinangguni ng isang natatanging tagakilala na tinatawag na CAMID. Kahit na ang lahat ng iba pang mga katangian ay pantay, ang CAMID para sa isang gumagamit sa isang nabubuhay ang namespace ng pagpapatunay ay hindi magiging kapareho ng CAMID para sa gumagamit na iyon sa bago namespace. Maaari nitong mapahamak ang isang mayroon nang kapaligiran sa Cognos. Kahit na mayroon ka lamang ng kaunting mga gumagamit ng Cognos, kailangan mong mapagtanto na ang mga sanggunian ng CAMID ay umiiral sa MARAMING iba't ibang mga lugar sa iyong Nilalaman na Tindahan (at maaari ding umiiral sa labas ng iyong Tindahan ng Nilalaman sa mga modelo ng Framework, Mga Modelo ng Transformer, Mga Application ng TM1, Mga Cube, Mga Application ng Pagplano atbp ).

Maraming mga kostumer ng Cognos ang nagkamali na naniniwala na ang CAMID ay talagang mahalaga para sa nilalaman ng Aking Folder, mga kagustuhan ng gumagamit, atbp. Hindi ito maaaring malayo sa katotohanan. Hindi lamang isang bagay ng bilang ng mga gumagamit na mayroon ka, ito ay ang dami ng mga bagay na Cognos na kailangan mong alalahanin. Mayroong higit sa 140 iba't ibang mga uri ng mga bagay na Cognos sa loob lamang ng Content Store, na marami sa mga ito ay maaaring may maraming mga sanggunian sa CAMID.

Halimbawa:

1. Hindi pangkaraniwan para sa isang solong Iskedyul sa iyong Nilalaman na Tindahan na magkaroon ng maraming mga sanggunian sa CAMID (ang CAMID ng may-ari ng iskedyul, ang CAMID ng gumagamit na dapat na patakbuhin ng iskedyul bilang, ang CAMID ng bawat gumagamit o listahan ng pamamahagi dapat itong binuo ng email na output output , atbp.).
2. Ang bawat object sa Cognos ay may isang patakaran sa seguridad na namamahala sa aling mga gumagamit ang maaaring mag-access sa object (isipin ang "Tab ng Mga Pahintulot"). Ang isang solong patakaran sa seguridad na nakabitin sa folder na iyon sa Cognos Connection ay may sanggunian na CAMID para sa bawat gumagamit, pangkat at papel na tinukoy sa patakarang iyon.
3. Inaasahan mong makuha mo ang punto - ang listahang ito ay tuloy-tuloy!

Hindi bihira para sa isang malaking sukat ng Tindahan ng Nilalaman na maglaman ng sampu-sampung libong mga sanggunian ng CAMID (at nakita namin ang ilang malalaki na may daan-daang libo).

Ngayon, gawin ang matematika sa kung ano ang nasa iyong Ang kapaligiran ng Cognos at makikita mo na potensyal kang nakikipag-usap sa mga sangkawan ng mga sanggunian ng CAMID. Maaari itong maging isang bangungot! Ang paglipat (o muling pag-configure) ang iyong namespace ng pagpapatotoo ay maaaring mag-iwan ng lahat ng mga sanggunian na CAMID sa isang hindi malutas na estado. Hindi maiwasang humantong ito sa mga problema sa nilalaman ng Cognos at pag-configure (hal. Mga iskedyul na hindi na tumatakbo, nilalaman na hindi na nakatiyak sa paraang iniisip mo, mga package o cubes na hindi na naipatupad nang tama ang antas ng seguridad sa data, ang pagkawala ng nilalaman ng Aking Folder at gumagamit mga kagustuhan, atbp.).

Mga Pamamaraan ng Paglipat ng Cognos Namespace

Ngayon, alam na ang isang kapaligiran sa Cognos ay maaaring magkaroon ng libu-libong mga sanggunian ng CAMID na mangangailangan ng paghahanap, pagma-map at pag-update sa kanilang katumbas na bagong halaga ng CAMID sa bagong namespace ng pagpapatotoo, talakayin natin ang mga diskarte sa Mabuti, Masama at Pangit para malutas ang problemang ito.

Ang Magandang: Kapalit ng Namespace kasama si Persona

Ang unang pamamaraan (Pagpapalit ng Namespace) ay gumagamit Motio, Persona IQ produkto Sa pamamagitan ng diskarteng ito, ang iyong umiiral nang namespace ay "pinalitan" ng isang espesyal na namespace ng Persona na nagbibigay-daan sa iyo upang gawing virtual ang lahat ng mga punong security na nakalantad sa Cognos. Ang mga mayroon nang pangunahing punong security ay ilantad sa Cognos na may eksaktong parehong CAMID tulad ng dati, kahit na maaaring nai-back ang mga ito ng anumang bilang ng mga panlabas na mapagkukunan ng seguridad (hal. Active Directory, LDAP o kahit na ang Persona database).

Ang magandang bahagi tungkol sa pamamaraang ito ay nangangailangan ng ZERO ng mga pagbabago sa iyong nilalaman ng Cognos. Ito ay dahil maaaring panatilihin ng Persona ang CAMID's ng mga dati nang may punong-guro, kahit na sinusuportahan sila ng isang bagong mapagkukunan. Kaya ... lahat ng libu-libong mga sanggunian na CAMID sa iyong Nilalaman na Tindahan, mga panlabas na modelo at makasaysayang cube? Maaari silang manatili nang eksakto sa kanila. Walang kinakailangang trabaho.

Ito ang pinakamalayo sa peligro, pinakamababang diskarte ng epekto na maaari mong gamitin para sa paglipat ng iyong umiiral na kapaligiran sa Cognos mula sa isang panlabas na mapagkukunan ng seguridad patungo sa isa pa. Maaari itong gawin sa ilalim ng isang oras na may halos 5 minuto ng downtime ng Cognos (ang tanging downtime ng Cognos ay muling pag-restart ng Cognos sa sandaling na-configure mo ang Persona namespace).

Ang Bad: Paglipat ng Namespace gamit ang Persona

Kung ang madali, mababang panganib na diskarte ay hindi lamang ang iyong tasa ng tsaa, pagkatapos ay doon is iba pang Pagpipilian.

Maaari ring magamit ang Persona upang maisagawa ang isang Namespace Migration.

Nagsasangkot ito ng pag-install ng pangalawang namespace sa pagpapatotoo sa iyong kapaligiran sa Cognos, pagma-map (sana) ang lahat ng iyong mayroon nang mga punong security (mula sa dating namespace) hanggang sa mga kaukulang punong-guro sa bagong namespace, pagkatapos (narito ang kasiya-siyang bahagi), paghahanap, pagma-map at pag-update ng bawat nag-iisang sanggunian ng CAMID na mayroon sa iyong kapaligiran sa Cognos: ang iyong Tindahan ng Nilalaman, Mga Modelo ng Framework, Mga Modelong Transformer, Makasaysayang cube, Mga Application ng TM1, Mga Application ng Pagplano, atbp.

Ang pamamaraang ito ay may posibilidad na maging nakababahala at maiproseso ng masinsinan, ngunit kung ikaw ang uri ng tagapangasiwa ng Cognos na nangangailangan ng kaunting isang adrenaline Rush upang makaramdam ng buhay (at hindi bale huli sa gabi / madaling araw ng mga tawag sa telepono), kung gayon marahil… ito ang pagpipilian ba na hinahanap mo?

Ang persona ay maaaring magamit upang matulungan ang awtomatiko ng mga bahagi ng prosesong ito. Tutulungan ka nitong lumikha ng isang pagmamapa sa pagitan ng mga lumang prinsipal ng seguridad at mga bagong prinsipal ng seguridad, i-automate ang malupit na puwersa na "hanapin, pag-aralan, i-update" ang lohika para sa nilalaman sa iyong tindahan ng nilalaman, atbp. Ano ang maaaring i-automate ng Persona ng ilan sa mga gawain dito, magkano ng gawain sa pamamaraang ito ay nagsasangkot ng "tao at proseso" kaysa sa aktwal na teknolohiya.

Halimbawa - ang pag-iipon ng impormasyon sa bawat modelo ng Framework Manager, bawat modelo ng Transformer, bawat aplikasyon sa Pagpaplano / TM1, bawat aplikasyon ng SDK, na nagmamay-ari sa kanila, at ang pagpaplano kung paano sila maa-update at maipamahagi muli ay maaaring maging isang pulutong ng trabaho. Ang pag-coordinate ng mga outage para sa bawat isa sa mga kapaligiran sa Cognos na nais mong subukan ito at ang pagpapanatili ng mga bintana kung saan maaari mong subukan ang paglipat ay maaaring kasangkot sa pagpaplano at "down time" ng Cognos. Ang pagkakaroon ng (at pagpapatupad) ng isang mabisang plano sa pagsubok para sa pagkatapos ng iyong paglipat ay maaari ding maging isang bear.

Normal din na nais mong gawin ang prosesong ito muna sa isang di-produksyon na kapaligiran bago sinusubukan ito sa produksyon.

Habang ang Namespace Migration kasama si Persona ay gumagana (at mas mahusay kaysa sa diskarte na "Pangit" sa ibaba), mas nagsasalakay, mapanganib, nagsasangkot ng mas maraming tauhan, at tumatagal ng mas maraming oras ng tao upang maisagawa kaysa sa Namespace Replacement. Karaniwan ang mga paglilipat ay kailangang gawin sa mga "oras na walang pasok", habang ang kapaligiran ng Cognos ay online pa rin, ngunit pinaghigpitan ang paggamit ng form ng mga end user.

Ang panget: Mga Serbisyo ng Manu-manong Paglipat ng Namespace

Ang pangit na pamamaraan ay nagsasangkot ng hindi maibabalik na diskarte ng pagtatangka na mano-mano lumipat mula sa isang namespace sa pagpapatotoo patungo sa iba pa. Nagsasangkot ito ng pagkonekta ng isang pangalawang namespace sa pagpapatotoo sa iyong kapaligiran sa Cognos, pagkatapos ay pagtatangka na manu-manong ilipat o likhain muli ang karamihan sa mayroon nang nilalaman ng Cognos at pagsasaayos.

Halimbawa, gamit ang pamamaraang ito, maaaring subukan ng isang administrator ng Cognos na:

1. Muling likhain ang mga pangkat at tungkulin sa bagong namespace
2. Muling likhain ang pagiging kasapi ng mga pangkat at mga tungkulin sa bagong namespace
3. Mano-manong kopyahin ang nilalaman ng aking mga folder, mga kagustuhan ng gumagamit, mga tab ng portal, atbp. Mula sa bawat source account sa bawat target na account
4. Hanapin ang bawat Itinatakda ng Patakaran sa Nilalaman ng Tindahan at i-update ito upang sumangguni sa mga katumbas na punong-guro sa bagong namespace sa eksaktong parehong paraan ng pag-refer sa mga punong-guro mula sa dating namespace
5. Muling likhain ang lahat ng mga iskedyul at i-populate ang mga ito ng kaukulang kredensyal, tatanggap, atbp.
6. I-reset ang lahat ng mga pag-aari ng "may-ari" at "makipag-ugnay" ng lahat ng mga bagay sa Tindahan ng Nilalaman
7. [Tungkol sa 40 iba pang mga bagay sa Content Store na makakalimutan mo]
8. Ipunin ang lahat ng mga modelo ng FM na may seguridad sa antas ng object o data:
   1. I-update ang bawat modelo nang naaayon
   2. I-publish muli ang bawat modelo
   3. Ipamahagi muli ang binagong modelo pabalik sa orihinal na may-akda
9. Katulad na trabaho para sa mga modelo ng Transformer, Mga Application ng TM1 at Mga Application ng Pagplano na nasiguro laban sa orihinal na namespace
10. [at marami pang iba]

Habang ang ilang mga Cognos masochist ay maaaring lihim na humagikgik sa kagalakan sa ideya ng pag-click sa 400,000 beses sa Cognos Connection, para sa pinaka-matalinong mga tao, ang pamamaraang ito ay may gawi na labis na nakakapagod, nakakapag-ubos na oras at madaling kapitan ng error. Hindi iyon ang pinakamalaking problema sa pamamaraang ito, gayunpaman.

Ang pinakamalaking problema sa pamamaraang ito ay halos palagi humahantong sa isang hindi kumpletong paglipat.

Gamit ang pamamaraang ito, (masakit) kang makahanap, at tatangkaing mapa ang mga sanggunian na CAMID na alam mo tungkol sa ... ngunit may posibilidad na iwanan ang lahat ng mga sanggunian na CAMID na iyong hindi alam ang tungkol sa.

Sa sandaling iyong mag-isip tapos ka na sa pamamaraang ito, madalas hindi ka Talaga tapos na.

Mayroon kang mga object sa iyong store ng nilalaman na hindi na nasigurado sa paraang sa palagay mo ay mayroon ka… mayroon kang mga iskedyul na hindi tumatakbo sa dati nilang pagpapatakbo, mayroon kang data na hindi na nasigurado sa paraang iniisip mo ito ay, at maaari kang magkaroon ng hindi maipaliwanag na mga error para sa ilang mga pagpapatakbo na hindi mo talaga mailagay ang iyong daliri.

Mga Dahilan Kung Bakit ang Hindi Masama at Pangit na Paglalapit ay maaaring maging Makakatakot:

• Ang mga Awtomatikong Namespace Migrations ay naglalagay ng maraming diin sa Content Manager. Ang inspeksyon at potensyal na pag-update ng bawat solong bagay sa iyong Nilalaman na Tindahan, ay maaaring magresulta sa sampu-sampung libong mga tawag sa SDK sa Cognos (halos lahat ay dumadaloy sa pamamagitan ng Content Manager). Ang abnormal na pagtatanong na ito ay karaniwang nagdudulot ng paggamit / pag-load ng memorya at inilalagay sa peligro ng pag-crash ng Content Manager habang nag-migrate. Kung mayroon ka nang anumang halaga ng kawalang-tatag sa iyong kapaligiran sa Cognos, dapat kang matakot sa diskarteng ito.
• Ang namespace Migrations ay nangangailangan ng isang malaking window ng pagpapanatili. Kailangang gumising ang mga Cognos, ngunit hindi mo nais ang mga tao na gumagawa ng mga pagbabago sa panahon ng proseso ng paglipat. Karaniwang kakailanganin nito ang pagsisimula ng paglipat ng namespace kapag walang ibang nagtatrabaho, sabihin nating 10 pm sa isang Biyernes ng gabi. Walang nais na magsimula ng isang nakababahalang proyekto sa 10 pm sa isang Biyernes ng gabi. Hindi man sabihing, ang iyong mga faculties sa pag-iisip ay marahil ay hindi sa kanilang pinakamahusay na pagtatrabaho gabi at katapusan ng linggo sa isang proyekto na ang kailangan mong maging matalim!
• Nabanggit ko ang Namespace Migrations ay oras at masinsinang paggawa. Narito ang kaunti pa rito:
  • Ang proseso ng pagmamapa ng nilalaman ay dapat gawin nang may katumpakan at nangangailangan iyon ng pakikipagtulungan ng koponan at maraming oras ng tao.
  • Kinakailangan ang maramihang mga dry run upang suriin ang mga error o problema sa isang paglipat. Ang isang tipikal na paglipat ay hindi perpekto sa unang pagsubok. Kakailanganin mo rin ang isang wastong pag-backup ng iyong Content Store na maaaring maibalik sa mga ganitong kaso. Nakita namin ang maraming mga samahan na walang magandang magagamit na backup (o may isang backup na hindi nila namalayan na hindi kumpleto).
  • Kailangan mong kilalanin ang lahat sa labas ang Tindahan ng Nilalaman na maaaring maapektuhan (mga modelo ng balangkas, mga modelo ng transpormer, atbp.). Ang gawain na ito ay maaaring kasangkot sa koordinasyon sa maraming mga koponan (partikular sa malalaking nakabahaging mga kapaligiran sa BI).
  • Kailangan mo ng magandang plano sa pagsubok na nagsasangkot sa mga kinatawan ng mga tao na may iba't ibang antas ng pag-access sa iyong nilalaman na Cognos. Ang susi dito ay upang i-verify kaagad pagkatapos makumpleto ang paglipat na ang lahat ay ganap na na-migrate at gumagana tulad ng inaasahan mo. Karaniwan itong hindi praktikal upang mapatunayan ang lahat, kaya't nauwi mong napatunayan kung ano ang inaasahan mong mga kinatawan ng sample.
• Dapat mayroon kang broad kaalaman sa kapaligiran ng Cognos at mga bagay na nakasalalay dito. Halimbawa, ang mga makasaysayang cube na may mga pasadyang pagtingin ay DAPAT maitaguyod kung pupunta ka sa rutang NSM.
• Paano kung ikaw o ang kumpanya na na-outsource mo ang paglipat ng namespace upang makalimutan ang tungkol sa isang bagay, tulad ng ... mga aplikasyon ng SDK? Kapag na-flip mo na ang switch, hihinto sa paggana ang mga bagay na ito kung hindi ito na-update nang maayos. Mayroon ka bang tamang mga tseke sa lugar upang mapansin kaagad ito, o ito ay ilang linggo / buwan bago magsimulang lumitaw ang mga sintomas?
• Kung nakaranas ka ng maraming mga pag-upgrade ng Cognos, maaari kang potensyal na magkaroon ng mga object sa iyong Content Store na nasa hindi naaayon na estado. Kung hindi ka gagana sa SDK, hindi mo makikita kung aling mga bagay ang nasa estado na ito.

Bakit ang Pinapalitan ng Namespace ang Pinakamahusay na Pagpipilian

Ang mga pangunahing kadahilanan sa peligro at pag-ubos ng mga hakbang na nailahad ko lamang ay tinanggal kapag ginamit ang paraan ng Kapalit ng Persona Namespace. Gamit ang diskarte sa Pagpapalit ng Namespace, mayroon kang 5 minuto ng downtime ng Cognos, at wala sa iyong nilalaman ang kailangang baguhin. Ang pamamaraang "Mabuti" ay tila isang hiwa at tuyong "walang-utak" sa akin. Ang gabi ng Biyernes ay para sa nakakarelaks, hindi nakaka-stress dahil sa katotohanan na ang iyong Content Manager ay nag-crash sa gitna ng isang Namespace Migration.