インフラSEのぼちぼち備忘録

非登録セキスぺの情シスがMicrosoft関連技術(Azure、Windows、Exchange、SystemCenter、SQL、Powershell)を中心とした備忘録を残していきます。圧倒的にインフラよりです。たまにネットワークのことも書きます。※本アカウントの発信内容、その他は所属する組織の見解ではありません。

CampusNetwork-laboの構築 その1 構成検討

前から構想はしていたのですが、少し心に余裕ができたので Hyper-V上にCampusNetworkのラボ環境を作っては消してを繰り返せるように整備していきたいと考えました。

以下の構成を作成してくれるスクリプトを作ってGitHubに公開予定。

f:id:kurone810:20190918022811p:plain
CampusNetwork-labo

とりあえず、ブログを書く癖をつけたいので小出しにしていきたい。

CISSP取得を目指して:コントロールフレームワークについて

ちょこちょこ勉強した内容を残しておこう。

以下の本を試し読み中。なかなか実務にも使えそうな体系だった知識が得られそう。 https://www.amazon.co.jp/dp/475710376X/ref=cm_sw_em_r_mt_dp_U_GfSwDb7G152EH

セキュリティフレームワークにつて

組織でセキュリティ要件を満たすためにコントロールフレームワークを採用することになるよ。

セキュリティフレームワークはISO27001やNIST SP 800-53 Revision4 があるけれども いずれにしても次の性質がある。 1.一貫性 2.測定可能 3.標準化 4.包括的 5.モジュール化

NIST SP 800-53 Revision4 は19のファミリーと285のコントロールで構成される。

個人的に逆に避けた方がいいんだなと解釈したアンチパターン

1.一貫性がなく、特定の手法や声の大きい人によってセキュリティ対策が変わる。 2.測定ができないためにルールが守られているのか、ルールを策定した有用性もわからない 3.標準化がなされておらず比較ができない。指針がないので差を検知できない 4.包括的範囲が考慮されておらず組織固有の拡張性がない 5.モジュール化されておらず、部分的な変更ができない

ユーザー企業によるDX推進エンジニアがエンジニアの処遇改善を目指して経営層に色々と打ち込みに行ってる話。

  • クビを覚悟で上の人に色々と意見をぶつけることで見えてきた色々について書いてみよう。
  • 個人としての処遇を改善したいだけなら改善できそうな会社に転職がおすすめ。チームの処遇を改善したいなら経営層に特攻するしかないかな思ったのがきっかけ。

非エンジニアな管理職が思っているほどコードを書くことだけに興味を持っているわけではない。

  • エンジニアは割と経営層がちゃんと経営をしているかを見ている。所属しているチームのビジョンが明確化されていること、WhyやWhatが重要
  • 自分の技術力で課題解決をしたいと思っているエンジニアは多いけれど、エンジニアにしかわからない課題への取り組みを非エンジニアのマネージャーに説明するのは難しい。(技術的負債とか)

非エンジニアの経営層は技術者のキャリアアップ指標を考える際に資格、知名度などを重視しすぎる。

  • 資格取得は技術力の客観的指標ではあるけれど、技術力を利用してどれだけ会社やチームに貢献したか?を評価されないとモヤモヤする。
  • 資格取得の是非は賛否両論だけれども、少なくとも高度な資格取得には攻略のために時間を費やすことが求められるので、実務課題とは少しズレたところに時間を使うことになる
  • メディア、SNSなどの対外露出がおおいエンジニアは確かに評価しやすいけど黙々とプロダクトを作っているエンジニアと優劣をつけないでほしいし、プロダクトを作ってるエンジニアの処遇の改善を課題として認識してほしい

非エンジニアの経営層が欲しいのは実はエンジニアではなく、広く浅い有識者だったりする。

  • それはエンジニアが考えているエンジニアじゃない可能性が高い。
  • 認識のミスマッチはエンジニアのモチベーションを極端に下げる。
  • 技術力を発揮できる仕事がないのにとりあえずエンジニアを確保しようとすると、確保されたエンジニアとしてもしんどくなる。
  • なんだかんだで結局外部ベンダーに委託前提で話が来るのでエンジニアリングさせてもらえない。

エンジニアが生産性を発揮するためのツールの必要性について、非エンジニアな経営層にもわかる資料作成を要求しがち。

  • エンジニアリング力より資料作成能力とプレゼン能力が重要?
  • それはエンジニアの一部ではあるけど、見落とされるエンジニアが多い。

専門以外の業務を依頼される。

  • 話が違うじゃないか。でも断ると評価が下がるんでしょ?

小さな費用で大きな効果を得られたエンジニアリングより、大規模プロジェクトを大規模な費用で遂行したPMが評価されがち。

  • 炎上しなかったプロジェクトより、炎上して火消しに成功したほうが評価されるマッチポンプ
  • 長期間障害が発生しなかったサービスより、障害が発生したけど復旧に超人的活躍をみせた方が評価されるマッチポンプ

エンジニアを大企業の枠組みで個人評価するとつらい。

  • DBエンジニア、ネットワークエンジニア、WEBエンジニア、クラウドのエンジニア、AIエンジニア、、、流行りはあるけど個人評価で優劣を付けるのは慎重に

もう少し、しっかりとエンジニアが戦っている課題の理解に歩み寄ってほしい。

  • エンジニアの言葉は非エンジニアには習得していない外国語に聞こえるかもしれないけれども先ずは自社のエンジニアと対話してほしい
  • ただエンジニアは目の前の課題をできるだけ早くソフトウェアをリリースしようと頑張っているので、まず対話の重要性を明確に

他社事例を参考にするのはいいけど社内の実情に合うように継続的改善は必要

  • 他社の成功事例を参考にするのはいいと思う。失敗事例からの学びからも目を背けないで
  • 時代はAIだ!ビッグデータだ!IoTだ!とか流行り"だけ"でエンジニアを確保すると碌なことないですよ。

minishiftが動いたり動かなかったりする。

最近minishiftを利用しており、WIndows10ユーザーとしてはHyper-vで動かしたい。

ただ"minishift start"を実施しても Starting Minishift VM ............................................................. が終わらずにタイムアウトすることがある。よくある。

安定した対処療法がすぐに見つかるかな?と思って再起動や仮想スイッチの指定などをやってみたのだけど 今のところよくわからないなぁ。

もう少し調べてみよう。

ちなみに正常に進んでいるパターン。

f:id:kurone810:20190523233211p:plain
処理が正常に進んでいる

解決。方法はとりあえずminishift update を実施した。OpenShift(OKD)としてのクラスターバージョンではなくminishiftのアップデートが影響?まだよくわかっていないけれどもとりあえずどういうことのようです。 しっかり調べないとな。

minishift update

Do you want to update from 1.33.0 to 1.34.0 now? [y/N]: y Downloading https://github.com/minishift/minishift/releases/download/v1.34.0/minishift-1.34.0-windows-amd64.zip 8.83 MiB / 8.83 MiB [=====================================================================================] 100.00% 0s 65 B / 65 B [=============================================================================================] 100.00% 0s

Updated successfully to Minishift version 1.34.0.

Current Installed add-ons are locally present at: C:.minishift\addons The add-ons for 1.34.0 available at: https://github.com/minishift/minishift/tree/v1.34.0/addons

Do you want to update the default add-ons? [y/N]: y Default add-ons will be updated the next time you run any 'minishift' command.

Docker for Windows / Docker Desktop でimageのpullがエラーとなる件

わけあってLinuxのコンテナを触ることになったわけです。 Windows コンテナーじゃなくて、Linuxのほうです。

で、手元にWindows機しかなかったので、どういう方法でDockerを試そうか考えて とりあえずchocolaty 経由で以下を入れてみました。

choco install docker-for-windows

で、powershellからdockerコマンドが使えるようになったので、試しにpull。

docker pull php

以下エラー。

Error response from daemon: Get https://registry-1.docker.io/v2/library/php/manifests/latest: unauthorized: incorrect username or password

f:id:kurone810:20190207013039p:plain

調べてみてもよくわかりませんでしたが、 Docker.WPF.HttpClientHelper.HandleStatusCode(HttpResponseMessage response) が例外投げてました。

ということで、 Check for Updates してみたところ回復しました。

f:id:kurone810:20190207012849p:plain

なんかよくわからんが動いてるからよし!

【セキュリティ②】情報セキュリティーはリスクマネジメントの一つです

つらつらかいてみよう。

まず、大前提として経営戦略は難しい。

セキュリティも難しい。

 

単純に"維持する"ことは難しい。

 

10年間黒字であり続けて従業員に十分な給与を払い続けることと同様に

10年間情報セキュリティインシデントを起こさないことは難しい。

 

経営戦略で言うとリスクマネジメント。

1特定・把握して、2分析・評価して、3対策する。

当たり前ですが、

当たり前にことを実践し続けるのって難しいと思うんですよ。

 

今回は1

特定・把握にのみ絞って考えてみます。

 

そもそもどうやってリスクを特定把握するのか?ですが。

 

一つの案としてルール化するというのがあるかと思います。

セキュリティ脆弱性検知とか。

 

しかし、ルール化は諸刃の剣でルール史上主義だとルールから漏れたリスクを特定・把握できなくなります。

 

ルール外のリスクを特定把握する方法としてはTBM/KYとかインシデントレポート、ヒヤリハットがあるとおもいます。

TBM/KYやヒヤリハットは専門家、属人化します。

 

 

ルール化をすすめすぎるとヒヤリハットの未然事象の報告文化が養成されず

ヒヤリハットに頼りすぎると、属人化するため測定ができない。

 

 

ジレンマがあるとおもいます。

 

また書こう

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

【セキュリティ①】情報セキュリティーはリスクマネジメントの一つです。

背景

エンタープライズな環境にいると、よく聞くのが 「セキュリティーは大丈夫か?」という漠然とした管理職者からの問。

そんなことないです? 私はよくあります。

問題点

”情報セキュリティ”という言葉だけで技術的!よくわからん! 経営層の中で比較的ITが詳しい兼任CIO君よろしく!って感ないですか?

そしてそのCIOの部下に”よろしく!”って・・・・。

セキュリティ対策ってプロアクティブに動かないとダメだけど其れなりに費用もかかるし、経営の理解がないと動けたもんじゃないですよねー。 そこ権限委譲するなら経営の情報、権限くれないとつらい問題。

セキュリティという言葉をリスクマネジメントに変えてみる

言葉を変えるだけで、割と経営者が自分で考えて、協力しないといけない領域の問題なんだなという意識が生まれる気がしてます。

なぜそう思うかについては改めて書こう。