Note2449757(同じシステムの認証済RFCに置ける追加の認証チェック)を読み解く
こんばんは、カズヤんです。
最近、ブログを書く頻度を抑えてますが、書くときはしっかり書きます。
今日は、タイトルにもあるように12月度リリースのセキュリティNoteについて説明します。
ちなみにSAPはこういう技術情報を月次でリリースしているので、世界のSAPユーザはリリースと同時に確認し、自社システムにおいてどのような影響が出てしまうのかをその都度確認しています。私もお客さんに毎月重要Noteのリストを提出し、月次報告会にて説明するのがルールになっています。
今回は、Note2449757についてで、
同じシステムの認証済RFCに置ける追加の認証チェック
と言う題です。このままでは、意味がわからんすwww
現象をみると、
トランザクションSMT1で同じシステムへの明示的な認証済/認証関係は定義されていないにもかかわらず、認証済RFC接続を同じシステムの異なるクライアントまたは異なるユーザに確立することができます。(SAP Support Launchpadから引用)
と記載があります。
SAP Basisやって来て、頻繁にRFC接続と言う単語を聞きます。
RFCに関しては、下記を参照して欲しいですが、
RFC(Remote Fucntion Callの略)が、SAPシステム間の通信用インターフェースということを押さえておけば取り分け問題ないっす。
ちなみに、SAP GUI上では、Trcd:SMT1にて各システム(SID)において認証されているその他SAPシステムの詳細を確認および新規登録できるっぽいです。
で話それましたが、
Noteによると、
このTrcd:SMT1をわざわざ実行しなくても、同じシステム上なら自動で認証される設定になっている
らしいのです。
SAPは、クライアントというデータ構造をとっているので、各クライアント依存のデータがあったり、ユーザも使い分けられるので、同じシステム内でもクライアントとユーザ固有データが存在します。なので、デフォルトの設定で、同じシステム内でも、別クライアント、別ユーザを利用する際には、わざわざ認証がいらないということです。
これって、何が問題なのかと言いますと、
例えば、あるSAP開発機があり、クライアント500で、ユーザkazuyanという実行ユーザで特定ジョブを実行した際に、他のクライアント001とか005とかでもユーザkazuyanを実行ユーザとしてジョブが実行できてしまうため、セキュリティ的によろしくないということです。
これを回避するために、このNote2449757上に記載のあるカーネルパッチを適用することで、この認証のデフォルト設定を変更できるそうです。
ただ、カーネルパッチ当てたりしてシステムのグレードあげると、システムの別機能で不整合が起きてめっちゃ不具合起きるらしいので、カーネル関連の変更ってかなり避けたい作業らしいので、ほとんどの場合、無視した方がいいのかなと個人的に思います。
あと、今回の自動認証機能が問題になるのは、システムを「集中ユーザ管理」設定しているシステムにおいての話なので、そうじゃない場合はあまり気にしなくてもいいのかなと思います。集中ユーザ管理は、権限などをシステム内で一意にまとめてしまうため、今回の事例が問題になります。
まあ、著作権というか、重要な情報っぽいので、詳しくはSAP Support PortalにてSユーザログインし、確認いただけたらと思いますが、SAP経験者でもこのNote解読するの大変かと思いますので、理解の助けになれば幸いです。
私も今回のとこでRFCに関しては、見直しました。
今日は、ここまでにしますが、今回説明したNoteの解釈間違ってたりしたらぜひコメントください。
IPA試験の海外認証について
こんばんは、カズヤんです。
今日から、３連休ですね。
わたしは、今日も資格試驗に向けがり勉していますww
私自身が海外でエンジニアとして業務をしたいという願望があるので、
たまたま気になったのですが、IPAが認定している情報処理試驗って海外でも認証されていることってご存知でしたか！！？
あと、私のブログはSAP経験者の方々だけでなく、海外移住を目指しておられる方も多いため、東南アジアに興味ある方には有益な情報かと思います。
以前ブログにも書きましたが、日本人が海外でエンジニアをしたいってなったら、Engineering 関連の学位を持っていないとengineerとしての資質を評価していただけないようです。
下記の国々では、日本で取得した情報処理試験でエンジニアとしての能力を各国の指標で評価して貰えるようです。下記リンクをご覧下さい ↓↓
現状では、ASEAN中心の12カ国で認証を受けられるようです。
インド、シンガポールは優秀なエンジニアが多数在籍してしている方イメージが湧きますが、
韓国、中国とかはどうなのかww?
ベトナム、ミャンマーもインドに次ぐオフショア地域として勢いがあるので、ここでの認証も日本のSIerとしてはでかいですね(てか、そもそもSIerがオフショア候補先を東南アジアに寄せていったのを背景に日本政府が認証取りにいった感はありますが..)。
欧米の国々の認証が受けられないのはかなりいたいですね。
個人的には、先進国でSAPの仕事をしたいので、そこらの国の認証があってほしかったなあ..シンがポール認証は気になります..
と思った今日この頃です…
では、ここで失礼します..
saposcolについて
こんばんは、カズヤんです。
今日は、新年初出勤でしたが、年末年始も出ていたので、仕事モードであまり憂鬱な感じはしませんでした。なので、一発目から書いて行きます。
今回は、SAPの重要な機能の1つであるsaposcolについて説明します。
saposcolは名前の通りsapのリソース情報をOSから収集するための機能です。
私は、運用のチームに所属しているので月次報告書を作成する際に、CPU利用率やメモリ利用率を集計する必要があり、このsaposcolが収集したデータを閲覧します。
このsaposcolはSAPシステムとは別で存在し、os上で「ps -ef | grep sapos」みたいな感じで見るとsaposcol.exeみたいな名前のプロセスが存在するので、それがあったら、saposcolのプロセスが起動しているということです。
ちなみに、SAP GUI上にこのリソース情報を得るためには、Trcd:ST06を利用すると情報を確認できます。
saposcolの起動方法はosにより様々らしいですね。私のとこでは、HPUXとかWindows Serverとかなのであまり意識してなかったですが、おそらく運用やってるところなら、SAP停止・起動の手順書が存在すると思うのでそちらを確認して見ることをお勧めします。
てか、全部下記サイトに載ってるっぽいっすww
まあでも、SAPの仕組みを理解する上では重要なのでSAP Basis担当の方はぜひ覚えましょう。
今日は、ここで失礼します!!
明日は今週ラスト、頑張りましょう!!
国内SAPベンダー勢力図
こんばんは、カズやんです。
今日で、大晦日と元日のシステム変更作業終わりましたww
てか、大晦日の電車の空き具合がやばかったww
今日は、技術よりのことよりも、日本国内のSAPベンダーの競争力について見てみます。
今って、SAPバブルみたいなところがあってどこの会社も基幹システムとしてSAPを導入しているため、その過剰需要に応えるために多くの企業がSAP事業に参入しているのは言うまでもないことです。
SAPに関して、どこのベンダーが最も競争力が高いのかとか、指標がなかったのでイメージしづらかったのですが、どうやらガートナー社によって、国内のSAPベンダーランキングが発表されているようです。
2017年2月にリリースされたものなので、1年前の指標ですが参考になると思います。
下記をご覧ください ↓↓ 筆者の会社も入っていたのでテンション上がります ↑↑
引用）https://www.gartner.com/doc/reprints?id=1-3V872QJ&ct=170309&st=sb
この図はすごくわかりやすくて、水平軸に「Completeness of Vision(ビジョンの完全性)」、垂直軸に「Ability to Execute(実行力)」となっています。
お分かりかと思いますが、第1象限から第4象限まであり、以下のような位置付けが定義されています。なんかすごい経営学のフレームワークみたいですww
間違いなく、1番強いのは、Leadersの企業群です。一番悪いのは、Niche Playersの企業群です。残り2つ(Challengers、Visionaries)については、人によって、変わりますが、個人的には、リソース大きい方が有利な業界だと思うので、Challengersが強いのかなとか思ったりもします。
アビーム、アクセンチュアが第1象限に位置しているのは納得ですね。
JSUGの広告とかでもこの辺のベンダーはよくみますし、SAP Hanaの導入等も他のベンダーの先をいっているイメージがあります。アビーム以外は、規模の大きなベンダーなのでスケールメリットってとこだと思います。
第2象限は、SCSK、TCS、TISがありますね。TISはわかりませんが、商社系のSIerがいる傾向がありますね。SCSKに関しては、SAP以外にも、プロアクティブっていうERP製品を持っているので、SAPとの相性も良いような気もします。TCSは、三菱商事系の資本を背景に強い顧客基盤を持っています。GlobalのTCSがSAPの売上高半端ないと聞きます。
第3象限は、みてわかる通り、コンサルティング系ベンダーが顔を並べています。まあ、第1に技術者が少ないイメージがあります。コンサルティングのサービスはシステム戦略、要件定義やBPRがメインになるイメージがあります。Basis等のインフラ部分は弱い気がします。ただ、PwCに関しては、かなり熱心に採用活動をしているので、今後強そうな気がします。
第4象限は、謎にWiproが入ってますね。Wipro Japanはインド🇮🇳IT企業群SWITCHの一画で技術力は申し分ないと思います。ただ、SAPのランキングで国内でそこまで有名なイメージはなかったので以外です。個人的には、外資系の少数精鋭のベンダーは好きなので、Basisの技術者の方なんていたら会ってみたいですね。おそらくですが、TCS同様に、インドオフショアできるのがアドバンテージだと思うので、今後伸びるのでは？
このランキングを見て思うのが、ガートナーは海外の会社なので、グローバル企業を主に評価しているイメージがあります。実際、SAPを日本でやっていると、他にも有名で勢いのあるベンダーは実は結構あります。JSOLとか入っていないの意外でしたwwwあと、個人的に気になっているのがBeeXですね。クラウド移行に強みを持つベンダーで超勢いあります。私もめっちゃ移りたいwww
ただ、どうやらガートナーもこのことには触れていて、ランキングを出す時の定義を細かく載せているのでそこは確認してください。まあ、こういうランキングって完璧じゃないので、目安ぐらいな感じで捉える感じでいいと思います。
そんなこんなで自分のファームも載ってたのでテンション上がりましたが、今後もっと個人でも戦えるように力をつけていきたいと思います。
年末に書いたブログ記事の内容を今年度の抱負としてまた1年頑張っていこうと思います。
では、今日はここで失礼します
スキルと今後について
こんばんは、カズやんです。
今日は、SAP Basisコンサルタントとしての私のスキルについて触れると共に今後必要となるスキルを検討し、来年2018年の目標としていこうと思います。
第１に今年は運用チームの一員として2つのプロジェクトに所属して、多くを経験させてもらいました。
具体的には、
・移送適用作業
・SAP正常稼動確認
・ユーザ作成
・ DBパフォーマンスチューニング(インスタンスメモリ拡張)
・ジョブ設定
・障害対応(DB障害、ロックテーブルオーバフロー)
・SAP起動・停止スクリプト作成
・DB再編成(作業実施予定)
・月次報告書作成
・月次報告業務
などこれぐらいが挙げられます。
私が今後目指す場所としては、3年間でSAP Basisの全ての変更作業を独力で実施するということです。そのためには、バックエンドの経験が圧倒的に足りていないのが現状です。例としては、
・SP適用
・Note適用
・クライアントコピー
・表領域拡張作業
・Ehpアップグレード
などが挙げられます。私の現在アサインされているプロジェクトの状況を鑑みると、来年2018年度には経験させてもらえる気配はあるので、とてもワクワクしています。
これらの作業を実施することで、SAP Basisコンサルタントとして、どこの会社でも通用するスキルを持っていることを証明できます。来年度9月までにはできそうなので、配属後1年以内に達成できる気がします。
確認ですが、資格の棚卸しも大切で、現在は、
Oracle BronzeのSQL試験は終わっていて、DBAを学習中の状況です。加えて、基本情報技術者試験の学習も継続的に実施している段階です。
SAPコンサル試験は現在SAP ADM100を学習しているため、これを来年度4月までに完璧に理解するという目標で業務を行なっています。
現状はとても順調に成長できていると言えそうです。
来年度、社内の体制がどのように変わるかに関しては、まだわかりかねますが、今後も頑張って行きますので改めてよろしくお願いいたします。
では、今日はここで失礼させていただきます。
Active Directory をSAP GUIで利用
こんばんは、カズやんです。
今日は、アクティブディレクトリについて考えてみようと思います。
皆さん、マイクロソフト社のアクティブディレクトリって使ったことがありますか？
アクティブディレクトリは、シングルサインオンを実現するために用いられた技術です。
シングルサインオンとは、アクティブディレクトリ内のクライアントであれば、一度認証を行うことで同ネットワーク内の認証をする必要がないという機能です。
さらに、このシングルサインオンの機能とは別に、アクティブディレクトリ機能を利用することで同時に、同ネットワーク内のクライアント端末の設定をドメインコントローラにて一括で変えることができます。
※ドメインコントローラはアクティブディレクトリの対象となるネットワークを管理する端末のことです。全てのクライアント端末はドメインコントローラの設定を反映します。
例として、下記のリンクを参照ください。
このURLによると、アクティブディレクトリの管理者テンプレートを利用する事で特定のアプリケーションの機能をドメインコントローラにて一括設定が可能になります。
言っていることが難しいと思うので、繰り返すと、例えば、Google内のプロキシ設定を管理しているネットワーク内のすべてのクライアントにて反映させたい場合には、ドメインコントローラにて、Google chromeの管理者テンプレートを導入して、プロキシ設定を更新することで、同じネットワーク内のクライアントにもchromeの変更内容を反映させることが出来ます。
今回、SAPに確認したところ、SAPでは上記URLのGoogleの管理者テンプレートを用意していないそうで、SAP GUIのOptionの設定情報を変更することはできないようです。
ただし、SAP Note 608781を確認すると、SAPにおけるActive Directoryのサポートはあるようですが、SAP GUI750でサポートしているかは現状ではわかりません。Noteが古すぎるからです。
現在、SAP GUI750用のActive Directoryのサポートに関するNote608781の最新版をSAP社が、作成しているようでとりあえず待ちましょう(おそらく、管理者テンプレートは無いはずですが...)
では、今日はここで失礼します。
DB再編成に挑戦
こんばんは、カズヤんです。
とりあえず、年末年始に担当案件で「DB再編成」っていう作業をやるので、その辺に関して書きたいと思います。ちなみにこの作業はSAP Basisコンサルタント業務経験としてLinkedinにかける普遍的なスキルです。ちなみに英語では、DB Reorganizationと言います。作業は丸2日ですが、超楽しみです。
この変更作業に関して、1ヶ月半前からアナウンスされていて、先輩に頼まれています。
私: DB再編成って何するんすか？
先輩: 断片化したDBのデータ領域をキレイキレイすることだよ^ ^
私: なるほど、DBの中をお掃除することなんですね！？
先輩: まぁ、そんなとこよ^ ^
で終わったんすけど、クソ適当か笑笑
実際には、
DB内の断片化したデータを整列させて、データ領域を大きくする作業
のことを指します。
Oracleの場合、運用中にデータは表領域内のセグメントの中にあるエクステントの中に、「使用しているデータ領域」と「空き領域のデータ領域」が混在し、データが断片化、使用していない領域が発生し、データベースのパフォーマンスが一挙に低下します。
これを食い止めるために、断片化しているデータをひとまとめにして、表領域の空き容量を増加させる作業をするわけです。ちなみこの断片化という言葉はかなり業界標準の言葉でググると死ぬほど出てくるのでSEの方は覚えましょうwww
以下、OracleHPでも解説がありますので参照ください ↓↓
ちなみに今回は、DB再編成の作業方法を記載します。
ここに記載する意味としては、DBを学んでいる方や、SAP Basis管理者からしたらこういう手順があったらかなり学習の助けになるからです。私は、Oracleの前DB2を学んでいたのですが、DB断片化是正の方法とかは出ても具体的な手順がなかったためイメージしづらく、大変苦痛でした。今回は、出血大サービスで細かく手順書きます。
手順としては、
1、バックアップ
2、事前作業
3、再編成作業
4、事後作業
となります。
1、バックアップ
バックアップでは、brbackupを利用してバックアップを取得します。brbackupはbrtoolsというSAP版Oracle特有の機能であり、Oracleのパラメータ変更や表領域拡張、今回の再編成などで利用する機能です。
2、事前作業
他のシステムはわかりませんが、どうやらテーブルによってはオフライン再編成でなく、オンライン再編成を実行する必要があるようです。
さらに、Oracle DBのみの作業となるため、SAPは停止しOracleのみを起動するため、この作業中では、Oracleに割り当てるメモリ領域を拡張して作業を行います。
でかいメモリリソースがあれば話は早いのですが、小さいとこでコツコツやるしかないのですw
3、再編成作業
ここから、再編成の作業に入るのですが、再編成を実施する上で下記の手順を踏む必要があります。これでも結構省略しています。大まかにこんな感じで作業を進めます。
要所要所に図を添付しますが、色の気持ち悪さは差し引いてみてくださいww
3-1.補助表領域の作成
→補助表領域にオンライン再編成でしか処理できない幾つかのテーブルを退避します。
3-2.特定テーブルのオンライン再編成
→既存の表領域にある特定テーブルを補助表領域に退避します。
3-3.対象表領域のエキスポート
→特定テーブル以外の表領域データをDBの外のOSの領域に退避します。
3-4.対象表領域の削除
→空っぽになった対象の表領域を削除します。バイバイサヨナラww
3-5.対象表領域の再作成
→今消したものと同じ表領域を作成します。さっきと違うのは、中身が綺麗ということですww
3-6.対象表領域のデータインポート
→DB外のOS領域に出した対象表領域データを3-5で作成した表領域の中にインポートします。つまり、中身が綺麗な表領域の中にデータを整列した状態で戻すイメージです。
3-7.特定テーブルの補助表領域からのオンライン再編成
→補助表領域に退避した特定テーブルを中身が綺麗な対象表領域の中に再編成コマンドで戻します。
3-8.補助表領域・エキスポートファイル削除
→中身が空っぽのこの表領域と、最後に、DB外のOS領域に出したファイルを削除して終わりです。もう不要です。さよならww
4、事後作業
最後に、統計情報更新してDBの変更内容をシステムに反映させます。そのあと、パラメータを戻したり、利用した補助表領域とエクスポートデータを削除して終わりです。
口では、簡単に言える再編成ですが、実際UNIXのようなコマンドベースのOSで作業をするとかなり緻密な計画のもと作業を行うため大変骨の折れる作業となります。今回は先輩に作業を計画を作成してもらっていますが、次回以降は私自身で作業を実施する必要がありそうです。
今回は、今私が学習しているOracleDBの内容がもろでるところでとても勉強になりました。実際、SQLのスクリプトも理解していないとできない箇所も多々あるのでありがたい経験です。
あとは、年始に作業終えて報告できたら幸いです。
今回の記事がBasisに携わる方々にとって有益であることを願っています。
SAP GUI 750 変更点(2)
こんばんは、カズヤんです。
先日にも投稿しましたGUI750の変更点ですが、もう1点設定ファイルの配布に関してもやっぱり触れておこうと思います。発端は、SAPでWindowsのアクティブディレクトリを使えるのか聞かれたことにもあるわけですが、こういう中央管理のやり方の代替策を探していたので、このファイル配布のことを紹介するわけです。
実際、私も利用したわけではないですが、Installation Guideに同様に掲載されている内容です。
SAP GUI for Windows 750では、
設定ファイル(SAPUILandscapeGlobal.xml、SAPUILandscape.xml)をWEBサーバからクライアントに自動で配布できる機能があるっぽいです。いずれも、SAP Front End Installation Guide 7.50に記載がある通りです。毎度、これの購読会みたいで大変申し訳ないのですが、日本語版が出ない限りこうやってしつこく見るしかないのが現状です...
こればっかしは、SAP社に頑張ってもらわないとです...
１、PULL リクエストによる配布（SAPの推奨はこっちらしい..)
最近、GitHubで流行っているからなのか、サーバ側で対象ファイルが変更された際に、クライアントPCが能動的に変更を取得する方法です。こちらは、WEBサーバとRemoteシェアによりファイル共有するっぽいです。矢印の方向がフローの流れです。
管理者サーバの以下のLandscapeFileOnServerのキーを下記パスで指定します。
HKEY_LOCAL_MACHINE\SOFTWARE\SAP\SAPLogon\Options (32 bits)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SAP\SAPLogon\Options) (64 bits)
以下の図がファイルの流れです。
２、PUSH リクエストによる配布
こちらは、データストレージ側のファイルで更新があった場合に、クライアント側PCで受動的に変更ファイルを取得するやり方です。こちらは、データストレージが必要になるのかな(?)
pullリクエストと同様に、キーを同じパスで指定し、データストレージで配布します。
既存のサーバにファイルを置けるはずなので、簡単に実装できると思います。
これ実践されたい方はInstallation Guideを参照してほしいです。
それで、これを実際にやられる方いらっしゃったらぜひ共有してほしいです。
