情報収集 - 2020/10/27
今週のおすすめ/一言所管
東証インシデントの最終レポートが出された。コンチプランを整備して08:00までに注文受付を止められて、かつ、事前に売買再開ルールを整備する方針んいなるっぽい。
AWSのNitro Enclavesがロールアウト。AWS IoTやWindows 10 (Enterprise)に備わってるRremote Attestation (PCR )な機能が備わることで、Trust基盤のプラットフォームができてきたかも?地味だけど、重要なリリースかと思われる。
高い精度をたもったまま倍のcompromisedアカウントを検知で切るようになったazure and identity protection
組織全体の端末の脆弱性重大度、OS毎の脆弱な端末、WIn10 Ver毎の脆弱な端末が一覧できるダッシュボード機能がpublic preview
Azure ADなどのディレクトリ上イベントをMicrosoft Defenderがサポート
すごく良さそう
https://gyazo.com/d9390150c19af8f09452eef36948e577
AWS Nitro Enclavesがavailable nowに。tokyoリージョンでも使えるぞ
Attestation Documentはうわっ、CBORだ...
PCRクエリとかAttestationとか
他のプラットフォームでも盛り上がりが激しい
サービス間mTLSが可能に
SQS +SNS FIFO queで順序ある重複のないメッセージ送信・処理が可能に
今まではルートユーザーでないと発行できなかった、署名付きURL・Cookieの証明書がIAMベースで発行可能になた
AWSのManaged Elastic Searchで立てるSIEM
Lambdaでログの正規化等を行っている
Dashboardも用意されている
CDKでデプロイ可能(cloudformation? 知らない子ですね...)
IAM roleに紐付けられたPermissionをCloudTrailに記録されない形でリストアップできてしまう「仕様」
AWSは正式に脆弱性とは認定してない
条件としては↓が揃ったとき
JSON 1.1 protocolの利用してる場合
APIアクションがpermissionに応じてユニークなエラーコードを吐き出す場合 (403)
actionが * の場合
AWS ShiledでDoS/DDoS Mitigationのイベントの場所、イベントの頻度と量、および過去 2 週間の最も一般的なイベントのグローバルヒートマップが表示される。おお。
AWS ShiledではL4までだが、AdvancedではL7も対象
ECSデプロイを早める方法
LBヘルスチェックのチューニング
HealthCheckIntervalSeconds : 30 -> 5sec
HealthyThresholdCount : 5 -> 2
LBコネクションDraining (target group)
deregistration_delay.timeout_seconds : 300sec -> 5sec
SIGTERMが送られるまでの時間
streaming接続やuploadの重いアプリは、処理前にSIGTERMされるかもなので注意
SIGTERM Responsivenes
ECS_CONTAINER_STOP_TIMEOUT: 30sec -> 2sec
SIGTERM -> SIGTKILLが送られるまでの時間差なので要注意
この値は最もおそいトランザクションのレスポンスtime の倍にするのがいい
SIGTERM後はサーバーをcloseしてサーバーによる新リクエストのlisterningを止める
Graceful Shutdown
コンテナImageのpull
ECS_IMAGE_PULL_BEHAVIOR: default -> once or prefer-cached
デプロイのステップ数をへらす
minimumHealthyPercent: 100% -> 50%
デプロイ前にタスクを減らして、新タスクをデプロイできる余地を増やす
maximumPercent: 200%
DIFのUniversal ResolverがION DIDをサポート
IONって使えるっけ
Sovring Ecosystem -> ToIP Layer Four governance framework
DID AuthやIdentity & DiscoveryにSIOPが多くみられる。
「Condatis」
OIDCサーバー, Evermym verify, SIOP SDKをバンドリングし、SSIとOIDCのブリッジをするsolution
WalletからはただのVerifierにみえ、RPからはただのOPに見えるようになる
SSI Issuerとverifierをいれ、proof requestテンプレをサポートしている
エンプラart&ck向けに以前、preに分類されてたreconnaissanceとresource developmentがtacticsとして追加
resource devはターゲティングをサポートするためのリソースの開発・購入など
stix配信してんだ。知らなかった
palo製品のCourses of Actionがあるもののactorとその中のtechniqueとindicatorがひと目でわかるのがいい
coaもpalo製品ではあるが、対応策として参考になる
Actionable Threat Objects and Mitigations(アクション可能な脅威オブジェクトとその緩和策)。playbook_viewreはなくなるかも
行政/会社/団体
官民ともにデータを活用するベースラインを構築し、共有することで価値の増幅を図る
申請のonce only、オープンデータ、データ標準・品質 on top of ID連携トラストサービスとベースレジストリ
ENISAがだしたツール。ISACを設立、開発、評価するオンラインツールキット
試してみたけど、ポチポチすると必要なToDOリストができるイメージ
イベント/勉強会/発表資料
正規表現でテスト名を絞ってグループ分けすることも可能
exactly once, at least once といってもキューはつらいので、ちゃんとアプリ側で設計しないといけないよ、という話
根本原因としては、製品マニュアルがバージョンの変更とともに更新されいてなかったこと
ベンダー側のマニュアルと実際の仕様に齟齬があったこと
共有ディスク停止時でも、確実に売買停止を行う手段を整備してなかったこと
07:04~08:00の間に売買停止できたかも
その場合は注文停止にできて、そうすれば証券側も当日復旧が可能だったかも?ということ?
障害発生時の売買停止 -> 再開にかかるルールがなかったこと
今後の課題
当日中に売買再開が可能になりそうなルールの模索
すでに発注された注文の取り扱いに関するルールの整備
コンチプランの整備
などなど
マニュアルの記載と実際の仕様の齟齬が生じた原因は、当該共有ディスク装置のオペレーティングシステムのバージョンアップにより製品仕様が変更された際に、マニュアルの記載が変更されていなかったこと
(前回の続き)東証側の調査により、メモリ故障時にFOするための設定値が入ってなかったことが原因とわかっていた。じゃあ、その原因はというと、、、というのが今回のレポート。結果、マニュアルには、メモリ故障時には自動切替がおこなわれると書いてあったけど、実際の仕様とは異なり、そしてその原因はバージョンアップによる変更差分がマニュアルに反映されていなかったということ。
つら...
SW障害で3hrほど取引が停止
その他
会計ビッグ4の今後の会計監査戦略。デジタル化だとか、監査方法だとか、体制だとか。
SSIでドコモ口座 <-> 銀行間の問題を和らげる!ってあったけど照合の問題じゃないよね...という感じの記事