クラウドは次の時代へ。これからのマルチクラウドを４人のスピーカーが語り尽くすへ参加した。その際のメモ。

ビックデータ分析基盤の成長の軌跡 – 白子 佳孝氏

・クライアント(リクルートと契約した企業)とユーザを結びつけるマッチングプラットフォームを開発している

・Mirror-Redshift
　・金曜日の夜にスナップショットをとり、そこからクラスターを作りデータ鮮度を求めない分析をするようにしていた
・2017年にBigQueryの導入によって、大規模に環境が変わった
　・データやユーザが増えても性能劣化が起きない、キャパブラ不要なDWHに乗り換える流れに

・今後やりたいこと

クラウドに関わる営業の本音、クラウドサービスの使い分け – 蔦野 岳人氏

オラクルとOracle Cloudについて

・オラクルは今大きな変革の中にある
　売り物がON-PREMISEからCLOUDへ
・Oracle Cloudはオンプレミスからクラウドへの完全互換性を謳っている
・ボトルネックを排除したアーキテクチャが売り
　元Amazonの人間とGoogleの人間が作っている
・IaaSでは低コストに力を入れている

今後営業に必要なマインドセット

・薄利多売のビジネスであることを理解すること
・クラウドは小さく入り込んで、大きく育てる
・営業先は情シスだけでなく、他部署へのアプローチも可能

マルチクラウドについて

・メリットはテクノロジーのいいとこどり、デメリットは運用の複雑化

シャドーITへの対策として -CASB-

・防いだ事例
　・Dropboxの私物利用
　・転職にあたり顧客データの持ち出し
　・インスタンスを起動して、コインマイニング

少し違った目線で考える、マルチクラウドのメリット、デメリット – 山田 雄氏

・ビールを奢れば、データ基盤の相談に乗ってくれるらしい

81

・81％ – クラウドを使っている企業がマルチクラウドである割合
・ActiveDirectoryやG Suiteなどを利用しているとマルチクラウドとしており
　なぜかマルチプライベートも入っているため割合が高め

各クラウドベンダーの姿勢

・AWSは否定派かも。CEOのインタビューから、複数のシステムの学習コストがかかる
　ボリュームディスカウントを考えると1つのほうがよい
・GCPはマルチクラウド、ハイブリッドクラウドを推奨している
　GCNextの3大メッセージに、ハイブリッド・マルチクラウド・オープン戦略がでていた

境界での問題にマルチクラウドは弱い

・S3からGoogleへデータを送信したときに、gsutilを使っていると中間ファイルが残るなど、スムーズに動作しない部分があった
　AWSへ問い合わせたところGoogleのツールなので、、Googleに問い合わせたところS3のため、、結局コードを追うことに

技術以外のメリットと、ちょっとしたデメリット

・AWSやGCPなど、人脈が広がり、横連携が強くなる
・サンフランシスコ(Google Cloud Next)、ラスベガス(re:Invent)にいける！
・技術的戦略がなく楽しい！BigQueryもRedshiftも利用できる
・両方の新サービスを追えない(勉強コストの増大)
⇒絞って学習している。現状GCPのビックデータ周りは把握しているが、AWSは理解できていない部分がある
・マルチクラウドという観点でのメンバ採用が難しい

マルチ クラウドだけでいいのか？ AI/IoT時代のクラウドのあり方 – 山﨑 亘氏

・ウフル：スワヒリ語で自由を表す

IoTのキーワード – 分散と更新

・例えば来場者の画像を取って、クラウドに送るような場合、次のようなデメリットが発生する
　・レスポンスが悪い
　・通信コストがかかる
　・セキュリティが心配
・上記場合は、データをエッジ側で処理すれば問題は解決する
・しかし運用していくと、次のような要望も出てくる
　・AIモデルの更新が必要
　・センサーデータ取得の間隔や位置も更新が必要
・これらの解決策として、enebularを開発している

ssmjp 2018/08 本当にあった怖い話に参加した。その時のメモ。

ssmjp:インフラ、運用がメインの何でもありの勉強会

Naomiさん

・ユーザ企業にて情シスをしており、以前の会社の話
・ファイルサーバやADなど、「Environment 45℃」で全サーバが停止
・推奨される最高周囲温度35℃
・サーバ増設による冷却装置付きのサーバラックのキャパオーバーが原因かも？
　2011年は輪番停電で扇風機がなかったが、ダイソンだけが在庫があった
・エアコンを数百万かけて設置することにした
　欄間を閉じると消防法のためスプリンクラーと警報機が必要になり高額となった
・しかしエアコンの納期は10月と夏を過ぎていたため、以下対策で乗り越えた　
　・ビル管へ空調24時間稼働依頼
　・空調温度をさげる
　・温度状況を計測して、サーキュレーターで対策
・外部監査はサーバラックに鍵をかけるという決まりがあったが、セキュリティリスクを許容して、事業継続リスクを優先で乗り切った

データセンタ運用であった本当に怖い話 @tcshさん

・予算のない部署のサーバラック
　・42Uフルで抜けない、差せない
　・ただし背面は寝るには最高の気温
　・熟睡していたら、あのラックの背面から足でているけど起こさないでね
　　・知らないうちに自分が設備扱い
・データセンターの電源容量枯渇
　・配電盤が溶融し、5秒後か5時間後にショートする状態に
　・シャットダウン大会
・電話局がリアルダンジョンで死ぬかと思った

皆一度は経験する、あり得ない話 流しのSEさん

・独立した上司に遊びにこないかと誘われ、客先に連れて行かれ、メイン担当者として紹介されたお話

今年最凶の怖いはなし 片山昌樹氏

・ナビプラスはセキュリティ全般をサービスにしている(インシデントレスポンス、フォレンジック、脆弱性対応)
・Huawai怖い
　・利用規約に口座番号や友人情報、リアルタイム位置情報やFacebookアカウントやTwitterアカウント情報などを取得を示唆する文章がある
　・米国政府から名指しで、個人情報を抜くメーカーと言われ、流通禁止の法律が施行されている
　　しかし、日本では大々的に販売されており、モバイルWi-Fiの90%はHuawai(わからないようにしている)
・試しにMateBook Eシリーズを調べてみたところ
　・Webカメラが写真を撮ろうとしている
　・マイクはミュートでも音を拾う
　・query.hicloud.comというHuawaiデータ取得用サイトなどに接続している
・Xiaomiを現在調査中
　・データのPOSTが多い
　・MDMサーバに定期的に通信している

　

運用におけるシェルの役割とそのあり方を考える – 山下和彦 氏

資料：運用におけるシェルの役割とそのあり方を考える

GMOペポバのサービス – ロリポップレンタルサーバ

・秒間2万8千アクセス/秒(DoSを受けた際はこれ以上)
・ビーク8Gbps

Shellに対するいくつかの考察

・Shell = Shell Script (bashで記載されたものを表す)
・RedMonk社(StackOverflow・GitHubでの人気度)によると、言語としては12位くらい

Shellの特徴

・メリット
　・パイプ、オプションを利用した強力な組み合わせ
　・ほとんどの場合は導入コストが低い(インストールの手間なし、依存性なし)
・デメリット
　・テスト実装、変化に強い実装、再利用性の高い実装は苦手

ライフサイクル観点からの考察

・パイプ、オプションが強力すぎて、熟練者でないと見にくいことがある
⇒開発効率化には最適であるが、複数人での運用保守には向いていない(運用の際に負債として残る可能性あり)
・携わるメンバがShellに詳しければ問題ないが、Shellに学習コストをかけるかというと、
　WEBエンジニアは覚えることが多くベターとは言えない

・例外として、USP研究所のようにShellに特化したユニケージ開発手法などが定着している場合もある
　・RDBを利用せず、テキストファイルによってデータを管理

言語特性観点からの考察

・長期的な運用には不向き
・変化が少ない局面については有効
　・バックアップスクリプト
　・監視系スクリプト

なぜ人類はShellをかかなくなったのか？

・Infrastructure as CodeによってLLやGoを書き始めた
・自動化の高度化
　LLやGolangで簡単にプロセスができ、人が介在せずとも処理ができるようになったため
　処理を集めてjob.shとして実行することなどを、自動化と呼ぶ時代ではなくなった

それでもShellが好きな人も

・人は得意な言語で書くため、評価にも反映させる

なぜGolang？

・システムプログラミングに必要なAPIが一通りそろっている
・可搬性が高く、サーバに配置しやすい

まとめ

・長期運用するなら、Shellを頑張るよりも、他の言語で対応したほうが幸せになる

知らなかったこと

・shellcheckというshellの記法をチェックするようなツールもある

サーバーやNW機器の構成・設定管理に困ってませんか？簡単に最新状況が把握できるインベントリ収集ツールの紹介 – 船井 覚 氏

資料：サーバーやNW機器の構成・設定管理に困ってませんか？簡単に最新状況が把握できるインベントリ収集ツールの紹介

Open-Audit

・コミュニティ版と商用版がある
・20ノードまでは管理可能
・エージェントレス型
・SNMP,WMI,SSHでアクセスして、情報を取得する

できないこと

・収集のみ、設定変更はできない
・時系列での履歴管理
・インデント管理、資産管理
⇒OpenPIEを利用すればできるように

OCS Inventory NG

・エージェント型
・コミュニティ版のみ

ノウハウ丸ごと共有します！ハートビーツの24/365体制を支える人材育成 – 倉持亘 氏

感想

・主体性(自分で考える)を大切にしている
・手を動かさないと身につかない
・障害時に大外ししないことを意識する
に共感した。

24/365を支える体制

・3交代制であり、3チームでローテーションしている
・1チーム5-6人で、役割がある(主担当と副担当、研修生)

目指す人物像

・なぜそうなるかを理解できる。自分で理解して、答えにたどり着ける人材(原則原理)
・技術はツールであり、このツールを利用して顧客へ価値を与えられる
・迅速に復旧までたどり着ける

人材育成におけるテーマ

・主体性
　自分で考えさせる。座学よりも、手を動かして理解してもらう(でなければ身につかない)

研修内容

研修生

・未経験者も雇うため、サーバ構築から障害対応までの基礎を教育する

サーバ構築研修

・目的：LAMP環境の仕組みを理解する
・タワーPCを渡して、あとはよろしく！チェックポイントは提示するが、構築の手順は提示しない
・やっていいこと、悪いことを学ぶ
・たくさん失敗させて、たくさん学んでもらう
・質問に対して、答えを伝えるのではなく、なるべく本人が答えにたどり着くように誘導する
・やったことはBacklogにエビデンスとして残してもらう
　・後で担当者が方向性があっているか確認する
　・ググってコピペしたものではないか確認するようにしている(自分の言葉でかけているか)

ロールプレイング研修

・目的：以下を身につけてもらう
　・技術だけでは顧客に価値を提供できない
　・技術がないと仕事はできない、
・顧客とHBのエンジニアという設定でロールプレイング
　顧客からアバウトな相談事を受けて、必要な情報を聞き取り、顧客の解決策を検討し、プレゼンしてもらう
・チェックポイント
　・Quick & Dirty (完ぺきではないが素早く)を実践できているか
　・顧客を理解できているか(サービスの理解、ビジネスの理解)
　・技術的に正しいことを言っており、もし不明瞭なことがあった場合に持ち帰っているか

障害対応研修＆実践

・障害対応フローを覚える
・調査コマンドを課題ベースで覚えてもらう
　使い方の詳細は説明しない。後ほど理解できているか確認する
・座学で学んだことを実際の障害で対応してもらう

フィードバック

・現場ではうまくいかないことも多いため、フィードバックを実施している
　・その場でのフィードバック
　・Backlogを利用したフィードバック
　　目的：振り返る機会を作る、指導者と研修生の認識をなくす
　　日報のようなものに、わからないことなどを記載してもらい、後日認識合わせをする
　・KPTを使った振り返り
　　・P(自分に足りないところ)：指導者の考えるPと研修生の考えるPのギャップを埋める
　　・T(Pをどうやって身につけるか):なるべく自分で考えさせる
　　・隔週実施

副担当

主担当面談

・主担当とは：シフト内の障害対応の責任者、すべての障害に目を通し、副担当に仕事を割り振る役割
・目的：主担当に必要なスキルを身につける
　・主担当のロールプレイング
　　・災害時のロールプレイング
　　・複数障害が発生した場合のロールプレイング
　　　・面談してフローを作成していくイメージ
　　　・チェックポイントとしては、優先順位をつけて、正しく仕事を割り振れるか、
　　　・論理的に切り分けて大外しせずに復旧までたどり着けるか

育成の課題

・指導者への指導
　人によって教え方が上手、下手がある
・フィードバックする時間の確保
　日頃の業務の中でフィードバックする時間がないときがある

質疑応答

・障害でパニックになる人に対してどうしているか？
⇒自分に自信がないことが原因だと思うため、小さい成功体験を積み重ねるよう教育している

・自分はできている思っている主担当に対してどのようにアプローチしているか？
⇒IT業界は流れが早いため、別途研修を設けている

「使ってみた」では終わらせない！ AWS GuardDutyを使ったサイバー攻撃の検出・分析45分スタートアップ講座 – 鈴木研吾 氏

資料：GuardDutyを使ったサイバー攻撃の検出と分析.pdf

感想 – というよりも知らなかったこと

・ArcSight、SplunkといったSIEMツールがある
・サイバーキルチェーンという標的型攻撃における攻撃手順を標準化したものがある
　これをもとに多段防御を検討することができる

GuardDuty 素晴らしいところ

・GuardDutyは検知だけのため、システム的な影響なし
　内部ではログをコピーして分析するため、遅延が発生することはない
　中の人に聞いた時も、ただただONにするだけでよいとのこと
・金銭面への影響についても、1ヵ月でどれくらいかかるかチェック可能

なぜGuardDuty

・AWSでは想定すべき脅威の種類が増えて、今までの検知ロジックだけでは不足している
　今までの検知が古いというわけではない

オンプレミス時代にはなかった想定すべき脅威の種類

・クラウドサービスとしてのアカウント
・リソースと権限
・動的にスケールするリソース
・Pay as you Goなリソース

GuardDuty in Folio

いくらかかっている？

・11アカウント全てON、$6.38/day
・SOCサービスは月間20万円ほど

誤検知ある？

・とても少ない
・もし誤検知があれば、その条件のアラートを無効にする機能が最近リリースされた

ユースケース？

・GuardDutyは集約する機能しかもたないため、CloudwatchからLambdaに流している
・検知したら、自動的にスナップショットを取得し、別VPCに展開し、フォレンジックするような仕組みを用意することも可能

Interact 2018に参加した。その際のメモ。

Recap: PowerShell Core – 高井 一輝氏

PowerShell Coreとは何か

Windows PowerShellとの違いについて

・Full .NET Frameworkに依存しないPowerShell
・クロスプラットフォーム
　LinuxやMACでも動作する。
・Windows PowerShellと互換性はあるが、基本的には違うもの
・WMFに(建前上は)依存しない
・SSHが使えるバージョンと使えないバージョンがある
・UTF-8(BOMなし)
・Modern Lifecycle Policy(新しいバージョンが出たら、半年の間にアップデートする必要あり)
・WindowsPowerShellと共存可能
・Windows PowerShellは、今後大幅な機能追加やエンハンスは行われない予定

Powershell Coreへ移行すべきか

No。ただし新しくコードをかく場合はPowerShell Coreを意識してもよいかも。

Powershell Coreを使うべき人

・クロスプラットフォームで利用したい人
・コンテナを利用してWindows管理したい人(開発スピードが早いプロダクトを利用している場合)
・PowerShellの動作を変えたい人(オープンソースのため、どうぞ)

注意点

・LinuxからWindowsへのWinRMの通信は失敗する
　最新のWindowsは認証されていないと受け付けないようになっており、PowerShellCoreでの認証周りの設定が難しい、らしい。

Windows Admin Center -Project Honolulu改め- – 指崎 則夫氏

※Inside Previewを利用しているため、変わってくる可能性も

Windows Admin Centerとは

・ブラウザを利用して、サーバを中央管理することが可能
・EdgeもしくはFirefox(ただし検証はされていない)が無難
・Chromeは画面遷移で認証エラーが多発する
・インストールが簡単(ただし証明書が絡むと少し手間がかかる)
・インストールファイルサイズが数10MBと軽量
・10GB以上のCSVがあれば冗長化構成をとることができる(2ノード以上のWindows Server 2016 failover Cluster)
・イベントログの確認、サービスの起動、ファイルの確認、レジストリの操作など管理できる

Admin Centerからサーバへのアクセス方法

・PowerShell or WinRMで接続するため、各サーバに許可設定をする必要がある

管理される側要件(古いOSについて)

・WinSV2012(WMF5.1以上)
・Win2008R2(WMF5.1以上)も最新のAdminCenterは管理できる
・ワークグループなWindowsはレジストリを登録することが必要

Microsoft Azure Global VNet Peering(仮) – 廣瀬一海氏

・VNet Peeringを利用すると、AzureがSDN(LVGREやSmartNIC(FPGA)を利用)であることを感じられる
・FPGAを利用してパケットチェックして機械学習を利用して、DDoS攻撃を処理している
・Azureは実質WANのようなもの。リージョン間のネットワークもMicrosoftで海底ケーブルを引き、すべて自社網を利用する唯一のパブリッククラウド
・東京リージョンから大阪リージョンへは2msレベル
・Azureは33000マイルの自社網を持ち、世界二位のグローバルネットワークを保有している(1位はペンタゴン)
・ExpressRouteは南極以外からは接続できる
・VNet PeeringはvNETのエンドポイントのBGPルーターを利用して実現している
　制限として10地点としか接続できない
・NW設計について、サブネット分離(Publicサブネット、Privateサブネット)という鉄板も世界をまたいだ設計を考えると、破綻する
　事業ネットワーク、論理ネットワークを考慮して、事業の展開に役立つような設計が大切

Interact 2018に参加した。その際のメモ。

Azureの契約直前・直後に意識しておくこと10箇条 – 足利 惟 氏

Azureそのものの管理の話。

自己紹介

・株式会社pnop所属。
・JAZUG運営メンバー。

Azureの契約プランを一度確認するべし

・サブスクリプションにはさまざまな契約プランがある。
・Visual Studio サブスクリプション(旧MSDNサブスクリプション)には月1万7000円利用できる特典がついている。

従量課金制

・使った分だけお支払い。基本はクレジットカードを利用し、Microsoftへ直接支払い。
・デメリット
　・会社のクレジットカードを作成する必要がある。(意外と敷居が高い)
　・請求書払いの場合、SendGridなどサードパーティと外部サービスは購入も支払いもできない。

Azure CSP(Cloud Solution Provider)

・Microsoftがオススメしている。
・サブスクリプション + パートナーが提供する付加価値。
・購入方法はパートナーの仕様に依存し、パートナー経由で購入する。法人のみ。
・デメリット
　・ASM(旧型式)のリソースは作成できない。移行の際にボトルネックになる可能性がある。
　・Azure Marketplaceの従量課金製品のほとんどは購入できない。(BarracudaのFW製品など)
　・Microsoftのサポートは購入できない。(パートナー提供のみ)

EA(Enterprise Agreement)

・大企業向けの一括購入プラン。基本的に1社1アカウント。
・年間160万円以上(？)利用する場合に利用可能。
・LPA(ライセンスプロバイダー)経由で購入。
・デメリット
　・年間使用分を事前に購入するため、年間金額を予測して購入しないといけない。
　　(余ったものは返ってこない。これはクラウド？)
　・Azure Marketplaceの購入はできるがほとんどの場合は別請求となる。
　　(足利さんはオラクルの製品を利用していて、別請求で100万円ほどかかったことがある。)
　・StorSimpleを利用したいのであれば現状EA一択。

MSA(MicroSoftAccount)と組織アカウントの違いを理解すべし

・MSA：個人で作成できるアカウントで、Microsoftが管理する。
・組織アカウント：企業が組織レベルで作成するアカウント。Azure ADに情報が格納される。
・MSAにリスクがあるため、Azureのアカウントは、すべて組織アカウントで管理することがオススメ。
・MSAのリスク
　・セキュリティポリシーが強制できない。
　　パスワードポリシー、多要素認証、監査など。
　・5年ログインしないとアカウントが無効になる。
　　Azureサブスクリプションの管理者の場合は、サブスクリプションが無効になる可能性がある。

Azure ADは最初に作っておくべし

・MSAを起点としてサブスクリプションを作成すると、メールアドレスに応じたAzure ADテナントが勝手に作成される。
・CSPはこのリスクはない。
・EAの場合は注意が必要。以下URLから先にAzure ADを用意可能。
　https://account.azure.com/organization/

Azure ADの管理者を理解するべし

・Azure ADの管理者はあくまでAzure AD内部を管理する。
　そのためユーザを作成しても、そのユーザはリソースにアクセスできない。
　(サブスクリプションの入力を求められる。もしくはサブスクリプション内で適切なロールを割り当てる必要がある。)

AzureADとサブスクリプションの関係を理解するべし

・Azure AD テナントに複数サブスクリプションを紐づけることが可能。
・Azure AD テナント間でサブスクリプションを譲渡可能。
・MSAはAzure ADではゲストユーザーとなる。
・ディレクトリを一緒にしておくとVNET Peeringを使うことが可能になる。

むやみに管理者ロールを渡すべからず

・RBAC(Role-Based Access Control)を利用して細かくリソース管理すること。
・管理者ロールはサブスクリプションを削除もできるし、所有者を無尽蔵に増やしていくことも可能。
・作業時のリスクを減らすために、適切な役割を割り振るべし。

リソース管理の便利機能を抑える

・リソースロック
　すべてのユーザに削除禁止、読み取り専用どちらかの状態にリソースをロックする機能。
・Azure Resource Policy
　リソースに関する規則を決める。RBACと違いデプロイ中のリソースプロパティに焦点。
　Dシリーズしか作成できない、東京リージョンにしか作成できないなどの制限を付与できる。
・Management Group(Preview)
　複数のサブスクリプションを管理するためのグループ。

サポートは必ず契約するべし

・Standardが値下げされてきている
・テクニカルサポートは有償サポート契約が必要
・パートナーになっている場合は、プログラム特典のサポートが利用できるかも
　(Microsoft Partner Network・MSDN・Signature Cloud Support)

感想、というよりも疑問

・AzureはAzure ADを1つ作成して、そこにユーザを作り、AD周りの権限を与える。
　サブスクリプションをAzure ADに複数割り当てて、ユーザにサブスクリプションごとにリソース権限を与える。
　という使い方であっているのかどうか？
・アカウント管理者(サブスクリプション管理者)とサービス管理者はわけたほうがよいのか？

参考 – わからなくて調べたこと

Azure サブスクリプションから CSP への移行【10/16更新】
Azure の購入方法

[AWS Black Belt Online Seminar] AWS Cloud9 入門を閲覧した。その時のメモ。

内容

特徴

・セットアップが手間、チーム開発の上でより容易なコラボレーションが必要、既存IDEはサーバレスに追いついていないといった課題解決のためのソリューション
・AWSサービスに直接アクセスできるため、シームレスな開発が可能。
・日本リージョンにはまだ来ていない。
・コスト節約のために、デフォルトでは30分利用しないとインスタンスを停止する。

利用パターンによって、3種類のセットアップ方法がある

・Team Setupでは、開発者チームや開発者チームなどのグループ分けが可能。(IAMグループを利用する)
・AdvanceTeamSetupでは、特別なポリシーを設定するで、TeamSetupより細かく権限制御することが可能。

一部拡張子についてはプレビューを利用可能

言語サポート状況について

・コード補完について ▲：実験的(ベータ版) △：localfunctionのみ ×●：パスを指定すれば利用可能

参考-リリースに関するAWSサービス図-

Harekaze Talk #1 @日本マイクロソフト株式会社に参加した。その際のメモ。

Office365等のお金セキュリティや色々話す – @hiww氏

・Office 365 を利用するのであれば、Office 365 Advanced Threat Protection サービスを利用すべし。
　簡単にメールのセキュリティを向上させることが可能。

EMACについて – @chouett0氏

EMACとは

・Extreme Malware Analyzing Challenge(造語、今後変わるかも)
・マルウェア解析の敷居を低くしたい
・まずはコミュニティ形成から、最終的には大会ができればよいと考えている

解析例

fileコマンドでファイルを判別
→HTMLファイルだった
→http,httpsでURLを検索
→whoisやaguse.jpを利用して中身を調べる
→アクセス先が2箇所あり、中国とロサンゼルス
→ロサンゼルスのサーバにアクセスするとマルウェアをダウンロード
→Ollydbgでマルウェアの動きを解析(バイナリであれば、stringsコマンドが有益かも)
　Wiresharkで通信状況、Process Explorerなどでプロセス状況を監視する
→Firefoxと連携して、他のマルウェアをダウンロードしている模様
　電源設定やディスプレイサイズでサンドボックスかどうか確認しているらしい

SCAP on Windows – @hogehuga氏

・Security Content Automation Protocol
　情報セキュリティ対策の自動化と標準化のための規格で、製品についてのID (CPE)、 脆弱性についてのID (CVE)、
　設定についてのID (CCE), 脆弱性の深刻さのスコアづけ (CVSS)、自動チェックのための言語 (OVAL)、
　チェックリストのフォーマット (XCCDF) などが標準化されている。
　https://qiita.com/bezeklik/items/8bf7d0ccf5cf916d778c
・CVSSについて、スコアだけでなくVectorを見なければならない(どの程度、攻撃しやすく危険なのかがより詳細にわかる)
・OpenSCAPをWindowsで動作させようとしたが、コンパイルがうまくいっていない状況。(バイナリ配布されていないためコンパイル)
・SCAPツールの大半はLinux用でWindows用はない。
　WSUSやグループポリシーがあるから不要？ただしセキュリティアップデートすることと、脆弱性がなくなることは別問題。
・SCAP実現時のメリットは、Linuxと同じように管理できるようになること。(CVSSなどで比較できるため、見通しがよくなる)
・SCAP実現時のデメリットとして、CVSSがわかっても、どのKBの更新プログラムが適用されていないのかはわからない。
　OVALdiが2014年以降、更新されていなさそう。

Windowsのセキュリティ機構について – @megumish氏

※Linuxと比較したときの話がメイン。

・Exploitする人がいるため、セキュアに保たなければならない。
・Exploitはメモリを書き換えることやあるいはメモリ上の資源を利用することで行われる。
・攻撃手法の種類について
　・XSS
　・SQL injection
　・Binary Exploitation
　　・Shell Code Injection
　　・Buffer Over Flow
　　・Return Oriented Programming
　　・Heap Exploitation
・VMMap(sysinternals)というツールでWindowsメモリの状況を確認すると、Linux(cat /proc/self/maps)と以下の点が異なることがわかる。
　・実行プロセスが最初にあるか、最後か。
　・heapメモリが散らばっている。(Linuxは一箇所に集まっている)
　・メモリ確保が少しづつ処理される。(Linuxは一気に確保する)

セキュリティ機構

・Full Relro(おそらくLinuxの話)
　外部バイナリを実行するときに、テーブルを利用する。
　Exploitはテーブル関数の書き換えることで予期せぬコードを実行させる。
　つまりテーブルを読み取り専用にすることで、セキュリティレベルを向上させる。
・DEP(Data Execution Prevention)
　実行可能領域にする必要のないメモリ領域に実行権限を与えないことで、Exploitを防ぐ。
・ASLR(Address Space Layout Randomization)
　OS起動時にバイナリの配置位置をランダムに変更する。
・CFG
　不正な関数が実行されていないか調べ、ROPなどの攻撃を防ぐ

まとめ

・そもそもLinuxとWindowsだとメモリ管理方法が違いすぎるため、攻撃の仕方や守り方も違ってくる。
・アップデートはしっかりしよう！

TechTrend #1：DevOpsにつながるソフトウェア開発プロセス再考に参加した。その時のメモ。
とても有益だった。

Countir

ファイナンスの未来に、答えを。
ブロックチェーンに取り組んでいるらしい。

DevOpsにつながるソフトウェア開発プロセス再考 – 長沢智治氏

・DevOpsの定義はないため、スコープは人によってさまざま
・「現場の解は現場にしかない」
　今日学んだことを実践するというよりは、自分たちのビジネスの立ち位置を考えて
　どう動くかチームでコンセンサスしていくことが重要

時代の流れとIT

・確立したビジネスがあり便利な道具としてITを使うモデルから、ITありきのビジネスモデルに変化してきた
　時代は変わる、つまりソフトウェア開発手法も変えるべきなのかもしれない
・ユーザがダイレクトに伝えられる時代になってきている
　そのため意思決定はユーザや競合他社の状況も含めて判断しなければならないため
　CMO(Chief Marketing Officer)の重要性が上がっている
・つまり意思決定権は市場が主導となっている
・より顧客にリーチするにはどうすればよいか？といった攻めるプロダクトも必要
・品質について、コード品質からシステム品質に重要性が移り
　現在はビジネスとして品質が担保されているかどうか？がポイントに
　コードの品質が悪くとも、ビジネスの品質が高いということもある
・ステイシーマトリックスでいうと90年代は単純であったが、現在は無秩序

アイアントライアングルと開発手法

・Quality(品質)はある程度守るという前提で
　Scope(要件)、Cost(費用)、Delivery(納期)の全ては固定できない
　どれを守るか？が重要
・ウォーターフォールとアジャイルで固定するものは違う
　ウォーターフォール：要件(S)を固定して、工夫してコスト(C)と納期(D)を検討する
　アジャイル：一定の期間(D)で、一定のチーム(C)で、できる範囲(S)を実施していく
・アジャイルではその時々で優先順位の高いもの、できるものから処理していく
　つまりスプリントごとに価値を見直すため、結果として従来型よりも価値を高めやすい
・アジャイルでは、このチームでこの期間で、どれくらいのことができるか？が明確となり、予測できるようになる

チームと集団

・集団でなく、チームであるべき
　・共通の目的と成果
　・やり方を共有
　・フォロー関係
・ビジネスする場合は集団も必ずある(開発班と企画班)が、DevOpsのためにはチームになる必要がある
　そのためには共通の目的を持つこと

知らなかったサービス

質問を匿名で受け付けるツール
https://www.menti.com/